Re: More GND + role inference woes

Edward Kmett ekm...@gmail.com writes: If this forced me to write those instances by hand, I could accept that as a tax for correctness. It means you can't GND any of the HasFoo dictionaries that lens builds, but meh. Am I correct in assuming that Bind, R1, R2, R3, and R4 are the problematic

LLVM and dynamic linking

# The Problem Dynamic linking is currently broken with the LLVM code generator. This can be easily seen by attempting to compile GHC with, GhcDynamic = YES DYNAMIC_BY_DEFAULT = YES DYNAMIC_GHC_PROGRAMS = YES BuildFlavour = quick-llvm This build will fail with a error along the

Re: More GND + role inference woes

Richard Eisenberg e...@cis.upenn.edu writes: Yes, I believe that's right. As far as I can figure out, these classes really *are* problematic, in that if we allowed GeneralizedNewtypeDeriving for them, there would be a way to subvert the type system. To make these derivable, we would need to

Ways issues with GhcDynamic=YES

I've spent much of the day trying to determine the root cause of, ... inplace/bin/ghc-cabal register libraries/ghc-prim dist-install /opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214/bin/ghc /opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214/bin/ghc-pkg

Re: LLVM and dynamic linking

Simon Marlow marlo...@gmail.com writes: This sounds right to me. Did you submit a patch? Not yet, I'm currently fighting through some build system issues which are preventing me from actually installing and testing the compiler on my ARM box. Note that dynamic linking with LLVM is likely to

Interface loading and dynamic linking

In trying to test my LLVM-dynamic linking changes, I've encountered some builds which fail with, Bad interface file: dist-install/build/GHC/CString.hi mismatched interface file ways (wanted dyn, got ) during `make install`. The failing command is `ghc-stage2`, invoked by

Re: Interface loading and dynamic linking

Ian Lynagh ig...@earth.li writes: On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote: DYNAMIC_BY_DEFAULT = YES Dynamic-by-default was a previous experiment to get GHCi to use the system linker. We now use dynamic-too instead. Causing GHCi to use the system linker is indeed my

Re: Interface loading and dynamic linking

Ian Lynagh ig...@earth.li writes: You shouldn't need dynamic-by-default. It should Just Work in HEAD, both unregisterised and registerised. Just to clarify, how does one configure GHCi to use dynamic linking now? Should I interpret your message to mean that it is already configured this way?

Re: Interface loading and dynamic linking

Carter Schonwald carter.schonw...@gmail.com writes: I think part of what Ian is saying is that the default config for a Perf build for HEAD will build the dylib versions of all the libraries. Or am I not understanding the question? eg: see the default make file

Re: LLVM and dynamic linking

Simon Marlow marlo...@gmail.com writes: This sounds right to me. Did you submit a patch? Note that dynamic linking with LLVM is likely to produce significantly worse code that with the NCG right now, because the LLVM back end uses dynamic references even for symbols in the same package,

Re: LLVM and dynamic linking

Simon Marlow marlo...@gmail.com writes: On 27/12/13 20:21, Ben Gamari wrote: Simon Marlow marlo...@gmail.com writes: This sounds right to me. Did you submit a patch? Note that dynamic linking with LLVM is likely to produce significantly worse code that with the NCG right now, because

Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code

David Luposchainsky dluposchain...@googlemail.com writes: Hey list, I am strongly in favour of the proposal. As a pedestrian-level GHC contributor, the *vast* majority of my time is spent trying to figure out what certain things do, when the answer could be found in a one- or two-line

globalRegMaybe and ARM

Hello Simon, b0534f7 [1] and the subsequent reversion f0fcc41d7 touched `includes/CodeGen.Platform.hs`, the former removing a panic in the case of `globalRegMaybe` being undefined for a platform and replacing it with `Nothing`. Recently I've found that my ARM builds (with -fllvm) crash at this

Re: ARM64 Task Force

Luke Iannini lukex...@gmail.com writes: Indeed, the float register stuff was a red herring -- restoring it caused no problems and all my tests are working great. So yahoo!! We've got ARM64 support. Yay! Awesome work! Cheers, - Ben pgpC53b1AIFVm.pgp Description: PGP signature

Re: Tentative high-level plans for 7.10.1

Austin Seipp aus...@well-typed.com writes: snip. We do not believe we will ship a 7.8.4 at all, contrary to what you may have seen on Trac - we never decided definitively, but there is likely not enough time. Over the next few days, I will remove the defunct 7.8.4 milestone, and re-triage

Re: Errors building GHC on iOS with LLVM = 3.4

Murray Campbell mur...@sonology.net writes: Hi, I am trying to help solve #9125 in which an ARM build creates binaries that mangle Float values. After a great deal of help from rwbarton (detailed in the comments) it would appear that the problem is actually in LLVM 3.0. (v3.0 is virtually

Re: GitHub pull requests

Richard Eisenberg e...@cis.upenn.edu writes: I've just finished reading this: http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/ For better or worse, I don't read reddit often enough to hold a conversation there, so I'll ask my question here: Is

Re: GitHub pull requests

Andreas Abel ab...@chalmers.se writes: On 05.10.2014 07:03, Ben Gamari wrote: and yet aren't willing to take the five (twenty?) minutes to familiarize themselves with Phabricator and the arc toolchain. Are you serious about this? I think your time estimate is a grand illusion. Fair

Re: GitHub pull requests

Richard Eisenberg e...@cis.upenn.edu writes: I absolutely believe that we should use the best tools available and that committed GHC contributors should have to learn these tools as necessary. Though I've had my problems with Phab and `arc`, I'm confident that this tool was chosen after a

One-shot semantics in GHC event manager

In ba2555ef and a6f52b19 one-shot semantics were added to event manager in `base`. If my understanding of this code is correct, in this mode the event manager will use only notify the user of the first event on a registered fd after which point the fd will need to be re-registered to get another

Re: One-shot semantics in GHC event manager

Thanks for your quick reply! Andreas Voellmy andreas.voel...@gmail.com writes: On Sat, Oct 11, 2014 at 12:17 AM, Ben Gamari bgamari.f...@gmail.com wrote: I'm a bit perplexed as to why the change was made in the way that it was. Making one-shot a event-manager-wide attribute seems to add

Re: One-shot semantics in GHC event manager

Andreas Voellmy andreas.voel...@gmail.com writes: Another way to fix usb would be to re-register the callback after a previously registered callback is fired. Of course it is cheaper not to have to re-register, but re-registration in the latest IO manager should be fairly cheap, so this may

Re: One-shot semantics in GHC event manager

Andreas Voellmy andreas.voel...@gmail.com writes: On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari bgamari.f...@gmail.com wrote: Thanks for your quick reply! What I'm wondering is what the extra complexity bought us. It seems like the same thing could have been achieved with less breakage

Re: One-shot semantics in GHC event manager

Andreas Voellmy andreas.voel...@gmail.com writes: On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari bgamari.f...@gmail.com wrote: Yes, but it will be invoked by GHC.Thread and any other callers of it will simply block indefinitely waiting for the thread that is running loop to give it up - which

Re: One-shot semantics in GHC event manager

Ben Gamari bgamari.f...@gmail.com writes: Andreas Voellmy andreas.voel...@gmail.com writes: On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari bgamari.f...@gmail.com wrote: Ah... so this is not useful to you. I guess we could add `loop` to GHC.Event's export list. On the other hand, I like your

Re: One-shot semantics in GHC event manager

Andreas Voellmy andreas.voel...@gmail.com writes: This is awesome. I'd like to try to recreate some of the evaluations for the multicore IO manager paper on that 40 core system at backspace. How can I get access to this? I'll jump on IRC - maybe it is easier to chat in realtime. Do you

Re: One-shot semantics in GHC event manager

Austin Seipp aus...@well-typed.com writes: The catch with such a change is that there is no macro to determine whether we're using 7.8.3 or 7.8.4, so it's harder for users to figure things out (they have to use `MIN_VERSION_base` from Cabal). But maybe that doesn'tm atter too much. So, yes, I

Re: One-shot semantics in GHC event manager

Austin Seipp aus...@well-typed.com writes: The catch with such a change is that there is no macro to determine whether we're using 7.8.3 or 7.8.4, so it's harder for users to figure things out (they have to use `MIN_VERSION_base` from Cabal). But maybe that doesn'tm atter too much. So, yes, I

Re: GitHub pull requests

Richard Eisenberg e...@cis.upenn.edu writes: I've just finished reading this: http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/ For better or worse, I don't read reddit often enough to hold a conversation there, so I'll ask my question here: Is

Re: One-shot semantics in GHC event manager

Kazu Yamamoto k...@iij.ad.jp writes: Hi, Andreas - want me to go ahead and get you some hardware to test Ben's patch in the mean time? This way we'll at least not leave it hanging until the last moment... I will also try this with two 20-core machines connected 10G on Monday. I

Re: One-shot semantics in GHC event manager

Kazu Yamamoto k...@iij.ad.jp writes: Hi, I measured the performace of GHC head, 7.8.3 and 7.8.3 + Ben's patch set. Server: witty 8080 -r -a -s +RTS -Nn *1 Measurement tool: weighttp -n 10 -c 1000 -k -t 19 http://192.168.0.1:8080/ Measurement env: two 20 core (w/o HT) machines

Re: One-shot semantics in GHC event manager

Kazu Yamamoto k...@iij.ad.jp writes: Hi, Hi Kazu, Andreas - want me to go ahead and get you some hardware to test Ben's patch in the mean time? This way we'll at least not leave it hanging until the last moment... I will also try this with two 20-core machines connected 10G on Monday.

Re: One-shot semantics in GHC event manager

Kazu Yamamoto k...@iij.ad.jp writes: Ben, This may be due to lacking INLINEs on definitions added in GHC.Event.Internal [1]. I'm currently in the middle of reproducing these results on an EC2 instance to confirm this. So far the results look much more consistent than my previous attempts at

Re: One-shot semantics in GHC event manager

Kazu Yamamoto k...@iij.ad.jp writes: I already pushed it. The commit in question is 5dce47eb8415eb31e1c6759b6f6a2ef5bfe32470. Thanks for the benchmarking! I believe this is in bgamari/ghc (for GHC 7.10?). I'm using bgamari/packages-base for GHC 7.8 and asking to push the same commit to this

Re: One-shot semantics in GHC event manager

Kazu Yamamoto k...@iij.ad.jp writes: Well, Bas was wondering whether this would be possible. At this point I'm a bit on the fence; on one hand it's not a crucial fix (we have a workaround in usb) and it may involve changes to exported interfaces (although not very high visibility). On the

Re: Proposal: Improving the LLVM backend by packaging it

Austin Seipp aus...@well-typed.com writes: Hi *, A few days ago a discussion on IRC occurred about the LLVM backend, its current status, and what we could do to make it a rock solid part of GHC for all our users. Needless to say, the situation right now isn't so hot: we have no commitment

Re: Proposal: Improving the LLVM backend by packaging it

Austin Seipp aus...@well-typed.com writes: Joachim, thanks for the forward and discussion. Just to rehash two points for the people reading at home: - I *do not* want to ship GHC specific patches to LLVM in the builds we use, anymore than anyone else does. I don't have any plans or even

Re: Proposal: Improving the LLVM backend by packaging it

Austin Seipp aus...@well-typed.com writes: On Sat, Nov 1, 2014 at 10:43 AM, Ben Gamari bgamari.f...@gmail.com wrote: I'm certainly not opposed to this idea and there is precedent in this area set by the Rust folks. That being said, I suspect some distributions may care pretty deeply about

Re: Proposal: Improving the LLVM backend by packaging it

Austin Seipp aus...@well-typed.com writes: On Sat, Nov 1, 2014 at 11:12 AM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, for the Distributions it would be most easy if the custom llvm would come within the source tarball, would be built by the regular build process and installed

Re: Proposal: Improving the LLVM backend by packaging it

Austin Seipp aus...@well-typed.com writes: Hi *, A few days ago a discussion on IRC occurred about the LLVM backend, its current status, and what we could do to make it a rock solid part of GHC for all our users. As if we needed another reason to do this, it seems that LLVM 3.6 will

Re: Proposal: Improving the LLVM backend by packaging it

David Terei d...@davidterei.com writes: Late to the conversation sorry. I think this sounds like a good plan. Given we are planning to stick with a vanilla LLVM but just fix the version, it seems it should make it reasonable to have distro’s support this. We can provide binaries easily, but

Status and future of the LLVM backend

I've written down some thoughts on the current status and future direction of the LLVM backend here [1]. Have a look when you get a chance. To summarize, * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework when the `$def` symbols are marked as internal * ARM is broken

Re: Status and future of the LLVM backend

Joachim Breitner m...@joachim-breitner.de writes: Hi Ben, Am Freitag, den 28.11.2014, 18:27 -0500 schrieb Ben Gamari: I've written down some thoughts on the current status and future direction of the LLVM backend here [1]. thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed

Re: Status and future of the LLVM backend

Joachim Breitner m...@joachim-breitner.de writes: [Resent, as ghc-dev does not like my other address. Sorry Ben] Hi, Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari: thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*. First, because it picked llvm-3.5

Re: Status and future of the LLVM backend

Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari: What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea? Indeed

Re: Status and future of the LLVM backend

Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Samstag, den 06.12.2014, 15:59 +0100 schrieb Joachim Breitner: any idea what might be causing this? I started the build from a fresh checkout. nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and

Re: Status and future of the LLVM backend

Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Samstag, den 06.12.2014, 16:19 +0100 schrieb Joachim Breitner: nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6 and will try with

Re: Status and future of the LLVM backend

Joachim Breitner nome...@debian.org writes: Hi, Am Montag, den 08.12.2014, 08:20 -0500 schrieb Ben Gamari: Again Google finds me a bug, but this time one that has no fix associated with it: https://ghc.haskell.org/trac/ghc/ticket/8951 Ben, can you help me out here? I've been

Re: Status and future of the LLVM backend

Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas: On 12/ 8/14 03:49 PM, Joachim Breitner wrote: So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if

Re: Out of memory mystery

Lennart Augustsson lenn...@augustsson.net writes: I'm running the 32-bit Windows version of ghc-7.8.3. Here are two runs: $ RunMu +RTS -A64M -h -Sstat.log -i1 -RTS -c Strat.App.Abacus.Main Compiling afresh Strat.App.Abacus.Main Compiled afresh Strat.App.Abacus.Main, 1302.84s $ RunMu

Re: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches

Johan Tibell johan.tib...@gmail.com writes: Ben, Is this something that worked in cabal-install 1.18.0.5 and that stopped working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you expected to be fixed in 1.18.0.6? These 1.18 and 1.20 releases just target a very few

Re: Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches

Ben Gamari b...@smart-cactus.org writes: Johan Tibell johan.tib...@gmail.com writes: Ben, Is this something that worked in cabal-install 1.18.0.5 and that stopped working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you expected to be fixed in 1.18.0.6? These 1.18

Re: performance regressions

Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Sonntag, den 14.12.2014, 22:37 -0500 schrieb Richard Eisenberg: snip - Travis has not picked up on these errors. unfortunately, travis is slighly less useful since a few weeks due to T5681 failing (possibly due to the use of

Re: performance regressions

Joachim Breitner nome...@debian.org writes: Hi, Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari: - Travis has not picked up on these errors. unfortunately, travis is slighly less useful since a few weeks due to T5681 failing (possibly due to the use of LLVM-3.4), but I’m

stg_init_finish

Hi Simon, A few of us are puzzling over a cross-compilation bug, #9920. stg_init_finish appears to be loading a zero Sp from the saved thread state. None of us have been able to figure out how execution makes it to stg_init_finish. The only references to the symbol are its definition in

Floating through small case analyses

Hello Simon, Today I've been working on trying to whip bytestring's Builder into shape [1,2]. The last remaining issue is a performance problem that appears to be due to over-zealous floating of some small literals in every GHC version I've tested (7.6, 7.8, and 7.10). The test case can be found

Re: Make one-shot a per-registration property

Herbert Valerio Riedel h...@gnu.org writes: On 2015-01-30 at 05:36:21 +0100, Austin Seipp wrote: You won't have permissions to push it to 7.10. I can try to get to it soon, but I make no guarantees until next week (out of town atm). CC Herbert, who can probably get to it more promptly than I

RE: Allowing rules to depend upon SimplCont

Simon Peyton Jones simo...@microsoft.com writes: | Is there a wiki page that describes this project? |- goals, and motivation |- design of the change |- any implementation notes | | Not that I'm aware of. I can perhaps fix this. Yes please! It is SO helpful. How does

RE: Allowing rules to depend upon SimplCont

Simon Peyton Jones simo...@microsoft.com writes: Ben Is there a wiki page that describes this project? - goals, and motivation - design of the change - any implementation notes Not that I'm aware of. I can perhaps fix this. I've lost context and #9661 is too long to suck up. A wiki

Allowing rules to depend upon SimplCont

In Bug #9661, Comment #12 Simon Peyton-Jones wrote [1], Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not give access to the context of an application (the `SimplCont`), but it would not be hard to make it do so. So if that is the right rewrite, then it'd be another useful

Re: Branchless implementation for literal case – is it worth it?

Joachim Breitner m...@joachim-breitner.de writes: Dear devs, in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that code like f :: Int - Bool f a = case a of 1 - True 5 - True 8 - True

Re: Some test data

Tamar Christina loneti...@gmail.com writes: Hi All, I’m currently busy rewriting the GHC-split perl script into Haskell and require some for the platforms I don’t have at the moment. I require an example file(s) for: - Apple Darwin - Sparc - PowerPC Linux - X86 Linux -

Re: [Haskell] ANNOUNCE: GHC version 7.10.2

Andrés Sicard-Ramírez a...@eafit.edu.co writes: Hi, On 29 July 2015 at 10:26, Ben Gamari b...@well-typed.com wrote: The GHC Team is pleased to announce a new bug-fix release of GHC, 7.10.2. Thanks for the release! FYI, there are various missing *.tar.xz files in the SHA256SUMS file

ANNOUNCE: GHC version 7.10.2

= The (Interactive) Glasgow Haskell Compiler -- version 7.10.2 = The GHC Team is pleased to announce a new bug-fix release of GHC, 7.10.2. There have been

Re: ANNOUNCE: GHC version 7.10.2

Hello again! See below for an important announcement regarding the `text` issue described earlier. Ben Gamari b...@well-typed.com writes: = The (Interactive) Glasgow Haskell Compiler -- version 7.10.2

Re: Building GHC master with GHC 7.6

Alain O'Dea alain.o...@gmail.com writes: On 21 July 2015 at 13:31, Ben Gamari b...@smart-cactus.org wrote: Hello everyone, Earlier today I merged a clean-up [1] to the master branch which removed some #ifdefs which ensured that the tree could be built with GHC 7.6 Thomas Miedema

Re: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2

Mikhail Glushenkov the.dead.shall.r...@gmail.com writes: Hi, On 29 July 2015 at 17:26, Ben Gamari b...@well-typed.com wrote: [...] The full release notes including a complete listing of the changes in this release can be found here, https://downloads.haskell.org/~ghc/7.10.2/docs/html

Re: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2

James M jmar...@eecs.berkeley.edu writes: There was talk from an earlier email thread of releasing the Haskell Platform at the same time as 7.10.2. I am referring to the weekly news of 2015/05/11: https://ghc.haskell.org/trac/ghc/blog/weekly20150511 and this email thread:

Building GHC master with GHC 7.6

Hello everyone, Earlier today I merged a clean-up [1] to the master branch which removed some #ifdefs which ensured that the tree could be built with GHC 7.6 Thomas Miedema correctly pointed out that some nightly builders may not be on GHC 7.8 yet. Do any of the nightly builders call in this

Re: Backporting srcLoc to the GHC 7.10 branch

Michael Snoyman mich...@snoyman.com writes: Hi Simon, We had a small pow-wow over here. We're already providing relevant customers with a custom-built GHC, and only using this feature internally to their codebases, so it's not a necessity to get this into upstream GHC 7.10. It would be nice

Re: Backporting srcLoc to the GHC 7.10 branch

Ben Gamari b...@smart-cactus.org writes: Michael Snoyman mich...@snoyman.com writes: Hi Simon, We had a small pow-wow over here. We're already providing relevant customers with a custom-built GHC, and only using this feature internally to their codebases, so it's not a necessity to get

Re: New release of GHC 7.8 to support OS X El Capitan

Oleg Grenrus oleg.gren...@iki.fi writes: Hi, first some background: there is an issue with having Haskell on the next OS X “El Capitan”: [1] caused by security updates in the operating system. The cause is too old `unix` package, the same issue as in [2] I would like to understand the

Re: New release of GHC 7.8 to support OS X El Capitan

Oleg Grenrus oleg.gren...@iki.fi writes: Hi, first some background: there is an issue with having Haskell on the next OS X “El Capitan”: [1] caused by security updates in the operating system. The cause is too old `unix` package, the same issue as in [2] I would like to understand the

Re: Duplicated typedef trips my gcc over

Gabor Greif writes: > Hi all, > > look: > > $ git grep "typedef struct LibDwSession_ " > rts/Libdw.c:typedef struct LibDwSession_ LibDwSession; > rts/Libdw.h:typedef struct LibDwSession_ LibDwSession; > > $ which gcc > /usr/bin/gcc > > $ gcc --version > gcc (GCC) 4.4.7 20120313

RE: Sphinx on Windows

Simon Peyton Jones writes: > I have not tried that. But 'pip' gives "command not found". > > Maybe I need something in my path? I appear to have python 2.7.5 installed; > it does not appear to have pip.exe. > Pip ships with Python 2.7.9 and later. Alternatively, you

Re: New error on linux

Simon Peyton Jones writes: > Clean build on HEAD on Linux is now giving a new error. > > Actual stderr output differs from expected: > > --- ./driver/T10970a.stderr.normalised2015-10-27 09:44:02.279188078 + > > +++ ./driver/T10970a.comp.stderr.normalised

Re: dll-split

Simon Peyton Jones writes: > It's just not my day. > Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure > in dll-split! Should dll-split be running at all on Linux > I'm looking into it. Give me a few minutes. I believe dll-split is run to ensure

Re: dll-split

Alan & Kim Zimmerman writes: > I think you need to remove Ctype and Lexer from > https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498 > Thanks Alan! That being said looking at the branch it's not entirely clear to me where this change came from. It doesn't appear

RE: New error on linux

Simon Peyton Jones writes: > gcc 4.6.3 > Alright, we'll need to figure out what to do about these differences. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Type-level error messages

Iavor Diatchki writes: >> I think that the branch should be in an OK state, except that it is not >> merged with the latest HEAD. > It does look pretty reasonable but keep in mind that there are a number of comments on the Phabricator Diff that still need to be

Re: stg_upd_frame_info still broken

Reid Barton writes: > I got lucky and found an error in the first place I looked. I have no way > to test it, but I expect that https://phabricator.haskell.org/D1382 will > fix the build on Windows, or at least make it closer to correct :) > I can test. Cheers, - Ben

RE: New error on linux

"Edward Z. Yang" writes: > OK fixed. > Thanks Edward! Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Type-level error messages

Simon Peyton Jones writes: > I’ve forgotten the state of your type-level error messages work. How’s it > going? > > Iavor Diatchki writes: > > > I think we should try to add it to 8.0.1. The current status is that > > the idea is implemented

Re: Type-level error messages

Iavor Diatchki writes: > Hello, > Hello! Very good timing on the message; we just finished discussing your work not more than an hour ago. You can disregard my message; I didn't notice yours before sending it. > On Thu, Oct 22, 2015 at 9:47 AM, Simon Peyton Jones

unboundKey and fromIntegerClassOpKey unique overlap?

Hello everyone, I noticed while looking through PrelNames that unboundKey and fromIntegerClassOpKey appear to share a unique in the master branch. Is this safe/expected? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing

Re: Warning suppression pragmas

Эдгар Жаворонков writes: > Hi Ben! > > I concreted some points in local warnings suppression pragmas wiki page > with specification. Hello! Things are definitely improving! I still think you should be more explicit about the possible uses here. In particular, what

Re: can't get haddock patch

Simon Peyton Jones writes: > Ben > What does this mean? (below) Does it mean you have not pushed something to > the haddock repo> > This happens when I'm on branch wip/T9858-typeable-ben2, in the main repo > > Simon > > git submodule update > > fatal: reference is not a

RE: Can't push to haddock repo

Simon Peyton Jones writes: > Well in utils/haddock/.git/config I see > [remote "origin"] > url = git://git.haskell.org/haddock.git > pushurl = ssh://g...@git.haskell.org/haddock.git > Note the difference in hostnames,

Re: Sphinx on Windows

kyra writes: > The Sphinx + GHC HEAD on Windows story is somewhat complicated. > Incidentally I've just managed to get it all working, thus I can share > some of my knowledge: > Thanks for writing this down, Kyra! These notes are very helpful. Would you like to add a comment to

Re: Segfault in a CoreLinted program (and a GHC-generated Core question)

Ömer Sinan Ağacan writes: > I have a very simple Core plugin that generates some functions. After my > Core-to-Core pass is done, I'm running the linter to make sure the Core > generated by my plugin is well-formed and well-typed. However, even though > lint > checker

Re: Warning suppression pragmas

Эдгар Жаворонков writes: > Hello Richard! > > Can you take a look at some sort of specification i wrote week ago? > I placed it here: > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas > I can imagine only two use cases, and i'm not sure about

Re: Doc warnings

Simon Peyton Jones writes: > I'm getting these warnings relating to the user manual. They seem non-fatal, > but are alarming. > Simon > > > reading sources... [ 66%] ghc > > > > looking for now-outdated files... none found > > pickling environment... done > > checking

Re: [ANNOUNCE] 7.10.3 release candidate 2

George Colpitts writes: > I get > > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 > make[1]: *** Waiting for unfinished jobs It looks like the build failed somewhere before this point. Could you provide a more complete log? Cheers, - Ben

Re: [ANNOUNCE] 7.10.3 release candidate 2

Ben Gamari <b...@well-typed.com> writes: > Ben Gamari <b...@well-typed.com> writes: > >> Hello everyone, >> >> We are pleased to announce the second release candidate for GHC 7.10.3: >> >> https://downloads.haskell.org/~ghc/7.10

Re: build system issue: some changes in libraries doesn't trigger required rebuilds

Ömer Sinan Ağacan writes: > Hi all, > > I'm having this annoying issue all the time: Whenever a `git pull origin > master` updates a library(one of the submodules, like `Binary`) a `make` > doesn't trigger required rebuilds(e.g. it doesn't rebuild libraries and tries > to

Re: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang

George Colpitts writes: > As I mentioned above from brew: > > $ brew upgrade openssl > brew upgrade openssl > Error: openssl 1.0.2d_1 already installed > I see. Does the file in question exist? What does find /usr/local -iname asn1.h say? Cheers, - Ben

Further custom type error questions

While preparing some additional documentation for Iavor's custom type errors work (which has been merged; thanks Iavor!) I noticed that Dominique Devriese has raised some additional questions on the proposal [1]. In particular, Dominique suggests that perhaps TypeError should simply be of kind

Re: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang

George Colpitts writes: > I did get compiling from source to work on the Mac. Unfortunately I'm not > sure what the problem was. > > I now see a new problem, not sure if it is a ghc problem or a library > problem: > > cabal install HsOpenSSL > ... > Building

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

Richard Eisenberg writes: > On Nov 4, 2015, at 11:12 AM, Peter Trommler > wrote: > >> It looks like a bug to me. > > I'm taking your "it" here to mean the fact that GHC is looking for > readelf on a Mac OS platform. I tend to agree -- I was

RE: [commit: ghc] master: Remove PatSynBuilderId (2208011)

Simon Peyton Jones writes: > | I don't think this would work in the case where there are no fields > | initialised? > > Oh yes, silly me. I was thinking that then we wouldn’t need to look at > 'labels' at all, but that's not true. > > Well, at least then I'd replace

  1   2   3   4   5   6   7   8   9   10   >