RE: Haskell on windows 7 installation instructions
Very helpful Artella. Your page is about *using* Haskell or GHC on Windows. That is usefully distinct from how to *build* GHC on Windows; there is a separate page on the Trac wiki about that. I’ve added a clarifying sentence to your page, and added links from each to the other. I’m cc’ing a few others who have Windows knowledge. I would love it if you guys formed a GHC-on-Windows Task Force, who tried to make sure that the Windows experience was always good. At the moment we have lots of Windows users but very few who are willing to help make it work, the recipients of this email being honourable exceptions. Simon From: Artella Coding [mailto:artella.cod...@googlemail.com] Sent: 25 June 2014 11:54 To: Simon Peyton Jones Subject: Haskell on windows 7 installation instructions Hi, I saw the installation instructions in http://www.gundersen.net/haskell-on-windows/ which cover installing in windows with msys (you suggested to the author that he put the instructions up on haskellwiki). However I wanted to install with the newer msys2 (which allows copying and pasting) and had quite a few problems initially (especially when trying to build hoogle). I have worked out all the issues, and have taken the liberty of writing the instructions at : http://www.haskell.org/haskellwiki/Windows which might require further editing. It took me a whole week to sort this out and thought it might be of help to others. I found that if you don't define the MSYSTEM environment variable (if you use the msys2_shell.bat instead of the mingw32_shell.bat or mingw64_shell.bat then this environment variable is not defined), then when you build hoogle you get some strange linker error messages https://github.com/haskell/cabal/issues/1950 . I didnt want to make the instructions too long, so omitted any explanation of why this environment variable is needed. Cheers ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Proposal: require Haddock comment for every new top-level function and type in GHC source code
I’d be OK with this, (it’s a bit like requiring signatures on all top level functions) but I don’t know how we’d enforce it. Do you think the requirement should be for all top-level functions or just exported ones? I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won’t be able to make much sense of it. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Johan Tibell Sent: 27 June 2014 10:51 To: ghc-devs@haskell.org Subject: Proposal: require Haddock comment for every new top-level function and type in GHC source code Hi! I found myself exploring new parts of the GHC code base the last few weeks (exciting!), which again reminded me of my biggest frustration when working on GHC: the lack of per-function/type (Haddock) comments. GHC code is sometimes commented with notes, which are great but tend to (1) mostly cover the exceptional cases and (2) talk about the implementation of a function, not how a caller might use it or why. Lack of documentation, in GHC and other software projects, usually has (at least) two causes: * Programmers comment code they think is complex enough to warrant a comment. The problem is that the author is usually a poor judge of what's complex enough, because he/she is too familiar with the code and tends to under-document code when following this principle. * Documenting is boring and tends to have little benefit the person writing to documentation. Given lack of incentives we tend to document less than we ought to. I've only seen one successful way to combat the lack of documentation that stems from the above: have the project's style guide mandate that top-level functions and types (or at least those that are exported) have documentation. This works well at Google. Anecdote: we have one code base inside Google that was until recently exempt from this rule and documentation is almost completely absent in that code base, even though hundreds of engineers work on and need to understand it every day. This breeds institutional knowledge problems i.e. if the author of a core piece of code leaves, lots of knowledge is lost. Proposal: I propose that we require that new top-level functions and types have Haddock comments, even if they start out as a single, humble sentence. I've found that putting even that one sentence (1) helps new users and (2) establishes a place for improvements to be made. There's a strong broken window effect to lack of comments, in that lack of comments breeds more lack of comments as developers follow established practices. We should add this requirement to the style guide. Having it as a written down policy tends to prevent having to re-hash the whole argument about documentation over and over again. This has also helped us a lot at Google, because programmers can spend endless amount of time arguing about comments, placement of curly braces, etc. and having a written policy helps cut down on that. To give an idea of how to write good comments, here are two examples of undocumented code I ran into in GHC and how better comments would have helped. First example In compiler/nativeGen/X86/Instr.hs there's a (local) function called mkRUR, which is a helper function use when computing instruction register usage. The first question that I asked upon seeing uses of that function was what does RUR stand for? Given the context the function is in, I guessed it stands for read-update-read, because R is used to mean read in the enclosing function and updating is related to reading so that must be what U stands for. It turns out that it stands for RegUsageReadonly. Here's a comment that would have captured, in a single sentence, what this function is for: -- | Create register usage info for instruction that only -- reads registers. mkRUR src = src' `seq` RU src' [] where src' = filter (interesting platform) src That already a big improvement. A note about the register filtering, which means that not all registers you pass to the function will be recorded as being read in the end, could also be useful. Aside: providing a type signature, which would have made it clear that the return type is RU, might also have helped in this particular case. Second example In the same file there a function called x86_regUsageOfInstr. It's the function that encloses the local function mkRUR above. I could figure out that this function has something to do with register usage, of the instruction passed as an argument, and that register usage is important for the register allocator. However, trying to understand in more detail what that meant was more of challenge than it needed to be. First, a comment more clearly explaining what computing register usage means in practice would be helpful: -- | Returns which registers are read and written by this -- instruction, as a (read,
Re: Two days old build breakage on i386.
The problem is that this instruction requires three separate registers, but cmpxchgl already reads and writes %eax leaving only two free registers (%ecx and %edx). You'll need to arrange to not use the complicated addressing modes with cmpxchg on i386, and keep the number of free regs required = 2. Really we ought to have 4 usable regs, but for that to happen we need to change the calling convention and swap R1 with Sp, but we can't easily do that because it needs a change in LLVM too (sigh). Cheers, Simon On 26/06/2014 19:39, Johan Tibell wrote: Here's some more debug output. Can someone interpret it: genRaInsn cmpxchgl %vI_n1nF,8(%vI_n1nD,%vI_n1nE,4) r_dying = [%vI_n1nD, %vI_n1nE, %vI_n1nF] w_dying = [] virt_read= [%vI_n1nD, %vI_n1nE, %vI_n1nF] virt_written = [] freeregs = FreeRegs 4282318848 assig= [n1nD :- InMem 0, n1nE :- InReg (RealRegSingle 2), n1nF :- InReg (RealRegSingle 3)] ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140626 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1nD assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle 2)),(n1nF,InReg (RealRegSingle 3))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 (i.e. it's the cmpxchg instruction which is causing the failure.) On Thu, Jun 26, 2014 at 8:17 PM, Johan Tibell johan.tib...@gmail.com mailto:johan.tib...@gmail.com wrote: I'm trying to understand the output from the register allocator: (GHC version 7.9.20140626 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1nD assignment: [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle 2)),(n1nF,InReg (RealRegSingle 3))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Without understanding exactly what's wrong, the message above suggests that we're trying to allocate a reg for n1nD, but there's already an assignment for that virtual reg, is that right? On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell johan.tib...@gmail.com mailto:johan.tib...@gmail.com wrote: Herbert pushed my revert for me a minute ago. Everyone should be good once they sync. On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell johan.tib...@gmail.com mailto:johan.tib...@gmail.com wrote: I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed this morning) which is fine. You should be in a good state now when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted. On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones simo...@microsoft.com mailto:simo...@microsoft.com wrote: git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 [master f958079] Revert Add more primops for atomic ops on byte arrays 23 files changed, 86 insertions(+), 1016 deletions(-) rewrite compiler/nativeGen/CPrim.hs (62%) delete mode 100644 libraries/ghc-prim/cbits/atomic.c delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 HEAD $ What now? Simon __ __ *From:*Johan Tibell [mailto:johan.tib...@gmail.com mailto:johan.tib...@gmail.com] *Sent:* 26 June 2014 13:25 *To:* Simon Peyton Jones *Cc:* Karel Gardas; ghc-devs *Subject:* Re: Two days old build breakage on i386. __ __ Just to make sure this is the same breakage, are you on an i386 Windows machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck. __ __ On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones simo...@microsoft.com mailto:simo...@microsoft.com wrote: Aaaargh! Once again the Windows build is broken. I am utterly stalled. Moreover -fregs-graph and -fregs-iterative now *silently* do nothing. At least they should elicit warnings saying that they are disabled pending the
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones simo...@microsoft.com wrote: I’d be OK with this, (it’s a bit like requiring signatures on all top level functions) but I don’t know how we’d enforce it. I think social enforcement is enough. If we agree that this is something we want to do and communicate that to ghc-devs@, put a note in our style guide, and kindly remind people to add comments when we do code reviews, we'll eventually end up with a culture of writing Haddocks. I think the most important part right now is that current contributors agree that this is something we want to do. Aside: people usually say that they find it hard to know what to document in their own code, because they don't know what others will find difficult. My advice is this: add a sentence or two about what the function does and why it exists, no matter how obvious you think that statement is. Do you think the requirement should be for all top-level functions or just exported ones? I take what I can get, but I think documenting all top-level functions makes sense in the case of GHC, as there's so much that goes on in our modules but we often only export a handful of functions. For example, compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 functions. For someone that wants to work on that module for the first time only have docs on those three functions is helpful, but likely not enough. FWIW I document all top-level functions in my projects (and when I don't I often regret it later). I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won’t be able to make much sense of it. Sure. Personally I would refer to the note from the function body if it talks mostly about the implementation, as opposed to how to use the function. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Two days old build breakage on i386.
On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow marlo...@gmail.com wrote: The problem is that this instruction requires three separate registers, but cmpxchgl already reads and writes %eax leaving only two free registers (%ecx and %edx). You'll need to arrange to not use the complicated addressing modes with cmpxchg on i386, and keep the number of free regs required = 2. Where's the best place to arrange for that? If I switch from using getAmode to computing the address into a temp register in StgCmmPrim will that ensure that the address is simple, or could some optimization replace my temp register computation with a complex address again? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Two days old build breakage on i386.
On 27/06/2014 12:23, Johan Tibell wrote: On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow marlo...@gmail.com wrote: The problem is that this instruction requires three separate registers, but cmpxchgl already reads and writes %eax leaving only two free registers (%ecx and %edx). You'll need to arrange to not use the complicated addressing modes with cmpxchg on i386, and keep the number of free regs required = 2. Where's the best place to arrange for that? If I switch from using getAmode to computing the address into a temp register in StgCmmPrim will that ensure that the address is simple, or could some optimization replace my temp register computation with a complex address again? There aren't any optimisations that happen on the instructions after codegen, and if there were, they would have to respect the same rule. So using a register is the right thing, yes. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
I would counter propose a place on hackage for people to type in or modify the documentation for functions, designed in such a way that the documentation would easily find its way back into the project's source code (with developer approval.) This way the documentation can be generated by people who only recently came to understand the function, so the questions a newcomer has are fresh in their mind. On Fri, Jun 27, 2014 at 4:19 AM, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones simo...@microsoft.com wrote: I’d be OK with this, (it’s a bit like requiring signatures on all top level functions) but I don’t know how we’d enforce it. I think social enforcement is enough. If we agree that this is something we want to do and communicate that to ghc-devs@, put a note in our style guide, and kindly remind people to add comments when we do code reviews, we'll eventually end up with a culture of writing Haddocks. I think the most important part right now is that current contributors agree that this is something we want to do. Aside: people usually say that they find it hard to know what to document in their own code, because they don't know what others will find difficult. My advice is this: add a sentence or two about what the function does and why it exists, no matter how obvious you think that statement is. Do you think the requirement should be for all top-level functions or just exported ones? I take what I can get, but I think documenting all top-level functions makes sense in the case of GHC, as there's so much that goes on in our modules but we often only export a handful of functions. For example, compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 functions. For someone that wants to work on that module for the first time only have docs on those three functions is helpful, but likely not enough. FWIW I document all top-level functions in my projects (and when I don't I often regret it later). I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won’t be able to make much sense of it. Sure. Personally I would refer to the note from the function body if it talks mostly about the implementation, as opposed to how to use the function. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
On 06/27/2014 01:19 PM, Johan Tibell wrote: On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones simo...@microsoft.com wrote: I’d be OK with this, (it’s a bit like requiring signatures on all top level functions) but I don’t know how we’d enforce it. I think social enforcement is enough. If we agree that this is something we want to do and communicate that to ghc-devs@, put a note in our style guide, and kindly remind people to add comments when we do code reviews, we'll eventually end up with a culture of writing Haddocks. I think the most important part right now is that current contributors agree that this is something we want to do. Aside: people usually say that they find it hard to know what to document in their own code, because they don't know what others will find difficult. My advice is this: add a sentence or two about what the function does and why it exists, no matter how obvious you think that statement is. Do you think the requirement should be for all top-level functions or just exported ones? I take what I can get, but I think documenting all top-level functions makes sense in the case of GHC, as there's so much that goes on in our modules but we often only export a handful of functions. For example, compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 functions. For someone that wants to work on that module for the first time only have docs on those three functions is helpful, but likely not enough. FWIW I document all top-level functions in my projects (and when I don't I often regret it later). I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won’t be able to make much sense of it. Sure. Personally I would refer to the note from the function body if it talks mostly about the implementation, as opposed to how to use the function. Notes could be moved into the module header if necessary so that they are rendered by Haddock. Alternatively, one function can contain the note and other places can refer to it by means of an anchor. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs My personal gripe of trying to read docs for GHC modules/types is that some older modules are in .lhs format which means we have to dive out of nicely-rendered HTML and go into source. Was there ever talk of converting Literate Haskell files into more Haddock-friendly format? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Make -fno-write-interface to all modes of GHC, not just -fno-code.
Hi, it seems that commit 05120ecd95b2ebf9b096a95304793cd78be9506e Author: Edward Z. Yang ezy...@cs.stanford.edu Date: Fri Jun 27 13:48:19 2014 +0100 Make -fno-write-interface to all modes of GHC, not just -fno-code. Signed-off-by: Edward Z. Yang ezy...@cs.stanford.edu broke stuff: libraries/base/GHC/IO.hs-boot:6:1: Failed to load interface for ‘GHC.Types’ There are files missing in the ‘ghc-prim’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 make[1]: *** Waiting for unfinished jobs libraries/ghc-prim/GHC/Classes.hs:24:1: Failed to load interface for ‘GHC.Magic’ It is a member of the hidden package ‘ghc-prim’. Use -v to see a list of the files searched for. libraries/ghc-prim/GHC/Classes.hs:26:1: Failed to load interface for ‘GHC.Tuple’ It is a member of the hidden package ‘ghc-prim’. Use -v to see a list of the files searched for. libraries/ghc-prim/GHC/Classes.hs:27:1: Failed to load interface for ‘GHC.Types’ It is a member of the hidden package ‘ghc-prim’. Use -v to see a list of the files searched for. make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Classes.o] Error 1 (https://s3.amazonaws.com/archive.travis-ci.org/jobs/28588528/log.txt) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
I don't think this is mutually exclusive with Johan's proposal. Let me suggest an amendment: Developers (both new and old) would be encouraged to submit patches adding or improving documentation in the source code. Documentation patches would be vetted as any others would be. Discouraging source code comments is the worst legacy of Unix. IMO (contradicting KR) even incorrect comments are better than none. Howard From: David Fox d...@seereason.com To: Johan Tibell johan.tib...@gmail.com Cc: ghc-devs@haskell.org ghc-devs@haskell.org Sent: Friday, June 27, 2014 6:26 AM Subject: Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code I would counter propose a place on hackage for people to type in or modify the documentation for functions, designed in such a way that the documentation would easily find its way back into the project's source code (with developer approval.) This way the documentation can be generated by people who only recently came to understand the function, so the questions a newcomer has are fresh in their mind. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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 ggr...@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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code
On 06/27/2014 03:26 PM, David Fox wrote: I would counter propose a place on hackage for people to type in or modify the documentation for functions, designed in such a way that the documentation would easily find its way back into the project's source code (with developer approval.) This way the documentation can be generated by people who only recently came to understand the function, so the questions a newcomer has are fresh in their mind. Are you asking for a wiki-like thing for documentation? There were a few times where this has been proposed such as https://github.com/haskell/haddock/issues/72 but in general it turns out that there's not enough interest for anyone to sit down and implement it and make sure it all works properly. Patches should be going straight to upstream rather than lingering on Hackage until someone notices them (even with automated tools, it's a pain). I doubt many people would use it for anything but typos because if you have enough knowledge about a function to document it, you're likely to already be involved with the project in some way and have means to report it properly. On Fri, Jun 27, 2014 at 4:19 AM, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones simo...@microsoft.com wrote: I’d be OK with this, (it’s a bit like requiring signatures on all top level functions) but I don’t know how we’d enforce it. I think social enforcement is enough. If we agree that this is something we want to do and communicate that to ghc-devs@, put a note in our style guide, and kindly remind people to add comments when we do code reviews, we'll eventually end up with a culture of writing Haddocks. I think the most important part right now is that current contributors agree that this is something we want to do. Aside: people usually say that they find it hard to know what to document in their own code, because they don't know what others will find difficult. My advice is this: add a sentence or two about what the function does and why it exists, no matter how obvious you think that statement is. Do you think the requirement should be for all top-level functions or just exported ones? I take what I can get, but I think documenting all top-level functions makes sense in the case of GHC, as there's so much that goes on in our modules but we often only export a handful of functions. For example, compiler/codeGen/StgCmmPrim.hs is 2,000 lines long but only exports 3 functions. For someone that wants to work on that module for the first time only have docs on those three functions is helpful, but likely not enough. FWIW I document all top-level functions in my projects (and when I don't I often regret it later). I agree that Notes have a different purpose. But it should be OK style to refer to a Note from a top-level function comment, even though Haddock won’t be able to make much sense of it. Sure. Personally I would refer to the note from the function body if it talks mostly about the implementation, as opposed to how to use the function. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: TypeLits question, how to build a Type Application with Symbol index
Hello,
I am a bit unclear on what you mean by programatically: do you mean from
within GHC or is that using something like Template Haskell?
-Iavor
On Thu, Jun 26, 2014 at 3:33 PM, Gabor Greif ggr...@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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Cabal for GHC 7.8
I noticed that the Cabal package doesn’t have a branch for ghc-7.8: http://git.haskell.org/packages/Cabal.git Is that intended? Maybe as a result the instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources to check out a branch from the *GitHub mirror repos* doesn’t work either. It fails with == running git submodule update Cloning into 'libraries/Cabal'... fatal: remote error: ghc/packages/Cabal is not a valid repository name Email supp...@github.com for help Clone of 'g...@github.com:ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed git failed: 256 at ./sync-all line 122. Manuel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Cabal for GHC 7.8
We could create a branch for 7.8, but I don't know which commit to branch of. If someone can figure out which cabal 7.8 shipped with we can add the branch. On Sat, Jun 28, 2014 at 7:48 AM, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote: I noticed that the Cabal package doesn’t have a branch for ghc-7.8: http://git.haskell.org/packages/Cabal.git Is that intended? Maybe as a result the instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources to check out a branch from the *GitHub mirror repos* doesn’t work either. It fails with == running git submodule update Cloning into 'libraries/Cabal'... fatal: remote error: ghc/packages/Cabal is not a valid repository name Email supp...@github.com for help Clone of 'g...@github.com:ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed git failed: 256 at ./sync-all line 122. Manuel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
