Re: cabal directory structure under /libraries/ for a lib that uses Rts.h

Well, which library should it be part of? Add it to the exposed-modules list there and it should get compiled. Edward Excerpts from Ömer Sinan Ağacan's message of 2014-09-30 22:54:52 -0700: Hi all, I'm trying to implement https://ghc.haskell.org/trac/ghc/ticket/5364 , I did the coding part

RE: Build time regressions

It sounds as if there are two issues here: · Should GHC unpack a !’d constructor argument if the constructor’s argument has a lot of fields? It probably isn’t profitable to unbox very large products, because it doesn’t save much allocation, and might cause extra allocation at

RE: mkCoreConApps vs. mkConApp

mkConApp assumes the let/app invariant holds, and hence does not need to carry around, decompose, or test the function type. Hence slightly more efficient. My instinct is to make mkConApp have ASSERT checks for the let/app invariant (and indeed the function having enough (-) arrows), but under

Re: Build time regressions

On Tue, Sep 30, 2014 at 7:44 PM, John Lato jwl...@gmail.com wrote: Hi Edward, This is possibly unrelated, but the setup seems almost identical to a very similar problem we had in some code, i.e. very long compile times (6+ minutes for 1 module) and excessive memory usage when compiling

Re: Is there a way to add a dynamic library to every link with GHC automatically?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 So now I'm wondering if there's a way to tell my GHC build that when it is built for this platform it should just always link against libcaps as well as whatever else? So, I think I've figured it out. Does this look like the best way to acheive

Re: Feedback request for #9628 AST Annotations

I have put up a new diff at https://phabricator.haskell.org/D297 It is just a proof of concept at this point, to check if the approach is acceptable. This is much less intrusive, and only affects the lexer/parser, in what should be a transparent way. The new module ApiAnnotation was introduced

Using cabal-install with GHC HEAD?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm running cabal-install 1.20.0.3 -- when I try to install packages for my cross-compiler built from GHC HEAD I get: ghc-stage1: ghc no longer supports single-file style package databases (dist/package.conf.inplace) use 'ghc-pkg init' to

Re: Using cabal-install with GHC HEAD?

Yeah, you'll need to update your Cabal to HEAD for all the latest support for package keys, etc. These changes happened in the past several weeks, so you might not have noticed if you don't rebuild especially frequently. On Wed, Oct 1, 2014 at 10:50 AM, Stephen Paul Weber

RE: Feedback request for #9628 AST Annotations

Let me urge you, once more, to consult some actual heavy-duty users of these proposed facilities. I am very keen to avoid investing design and implementation effort in facilities that may not meet the need. If they end up acclaiming the node-key idea, then we should surely simply make the key

Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590

Hi Malcolm, Withdrawing the packages from GHC's distribution is certainly a possibility. We did briefly raise that point when we talked yesterday too, but it wasn't discussed much. Perhaps some others feel the same, but I imagine more people would be OK with #2 above as opposed to eliminating

Re: Feedback request for #9628 AST Annotations

I was getting a bit lost between the idea and the implementation. Let me try rephrasing the idea in my own words. The goal: Capture inner source spans in AST syntax nodes. At the moment if ... then ... else ... captures the spans [if [...] then [...] else [...]]. We want to capture the spans for

RE: Feedback request for #9628 AST Annotations

Let me urge you, once again, to consult users. I really do not want to implement a feature that (thus far) lacks a single enthusiastic user. Please. Simon From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: 01 October 2014 16:13 To: Simon Peyton Jones Cc: Richard Eisenberg; Edward Z.

Re: Feedback request for #9628 AST Annotations

Thanks for the feedback and support. Alan On Wed, Oct 1, 2014 at 6:37 PM, Neil Mitchell ndmitch...@gmail.com wrote: I was getting a bit lost between the idea and the implementation. Let me try rephrasing the idea in my own words. The goal: Capture inner source spans in AST syntax nodes. At

Re: Feedback request for #9628 AST Annotations

Neil I looked into your proposed change in more detail, and I think it is flawed because it is trying to map the annotation back to itself. To start with we have a SrcSpan and the concrete AST value. We need to map the concrete constructor to the relevant annotation, which is of a different

Re: Feedback request for #9628 AST Annotations

I looked into your proposed change in more detail, and I think it is flawed because it is trying to map the annotation back to itself. Flawed because it is no better, or flawed because it won't work? In this scenario I am not sure that there is a benefit to splitting the ApiAnn type into

Re: Feedback request for #9628 AST Annotations

I am not sure that I understand your proposal correctly, but I interpret the requirement to map the Dynamic type to the TypeRep of the constructor meaning some kind of separate linkage between the Constructor and the specific annotation type. The key is that there is no linkage from the

Re: Build time regressions

Hi Simon, Thanks for replying. Unfortunately the field in question wasn't being unpacked, so there's something else going on. But there's a decent chance Richard has already fixed the issue; I'll check and report back if the problem persists. Unfortunately it may take me a couple days before I