Re: Upcoming GHC 9.4.8 release

Hello Zubin, > The fix for the issue (!11254) has been marked for backport and will > be included in the release. Thanks in advance! --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Upcoming GHC 9.4.8 release

Hello, Thank you for your effort. How can I confirm that fix for #23746 is included in GHC 9.4.8? Without this, I cannot take profile on M1 mac. I'm now taking profile on a remote Linux machine. It's very inconvenient. --Kazu Hi all, We hope to prepare the 9.4.8 release in the coming weeks.

Re: [Haskell] [ANNOUNCE] GHC 9.2.4 released

Hi, > On a Mac it is still necessary to do > > xattr -rc . > > before doing > > sudo make install For 9.2.4, "xattr -rc ." is not good enough on my Mac (upgraded to v12.5 today). "sudo spctl --global-disable" is necessary, sigh. --Kazu ___

Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available

Hi George, > I've duplicated the issue on both of my machines. It would be good to know > if anybody else is seeing it. Kazu, I know you have seen this in the past. > Do you get the same error installing rc1? > When I run sudo make install I get a popup that says: I had no problem on 9.4.1-rc1.

Re: [ANNOUNCE] GHC 9.2.2 is not available

Hi George, FYI: https://twitter.com/kazu_yamamoto/status/1500643489985761282 --Kazu > Thanks Ben > > When I do an install on macos Monterey 12.2.1 (Intel) I get > > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified > > > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari

Re: [ANNOUNCE] GHC 8.6.1 released

Hi Evan, >> Has anyone installed the OS X binary distribution? I get: >> >> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy >> libraries/ghc-prim dist-install "strip" '' '/usr/local' >> '/usr/local/lib/ghc-8.6.1' >> '/usr/local/share/doc/ghc-8.6.1/html/libraries' 'v p dyn' >>

Re: [ANNOUNCE] GHC 8.4.1-rc1 available

Hi Ben, > What you are seeing isn't a warning, it's an error. > 8.4.1 throws errors for Monoids missing Semigroup instances not because > of -Wsemigroup but rather because Semigroup is now a superclass of > Monoid. > > -Wsemigroup will likely be deprecated in a future release now since > we've

Re: [ANNOUNCE] GHC 8.4.1-rc1 available

Hello Ben, > As always, do let us know if you encounter any trouble in the course of > testing. Thanks for your help! I tried GHC 8.4.1rc1 to understand how SemigroupMonoid and MonadFail proposals work. GHC 8.4.1rc1 surely detects Monoid data types if they are not instances of Semigroup.

Re: Contributing Examples to the Documentation

Hi Sunjay, > If I use the doctest style, do I use ">>>" for the prompt? That's more a > Python thing. Maybe ">" would be more appropriate for Haskell? You should use ">>>". If you don't know doctest for Haskell, please read: https://github.com/sol/doctest#readme The following document

Re: Contributing Examples to the Documentation

Hi Sunjay, > Are there any modules with good code examples that I should use as a > reference? I want to include both the code and output of the example as if > the user was running ghci. Are there any guidelines for contributing > documentation? I would suggest to use the doctest style so that

Re: Simple "Hello World" Warp-based web server crashes on Ubuntu x86_64

Hi, > repro: internal error: ASSERTION FAILED: file rts/Schedule.h, line 137 > > (GHC version 7.10.3 for x86_64_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Aborted (core dumped) I can reproduce this on my 64bit Mac. But the code in

Re: GHC 7.10 complie time regression

Simon, > no it's not expected to take "much longer". Can you make a ticket > with a reproducible test case? OK. Now Filed: https://ghc.haskell.org/trac/ghc/ticket/10818 --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org

Re: GHC 7.10 complie time regression

Erik, no it's not expected to take much longer. Can you make a ticket with a reproducible test case? An make sure you are using ghc 7.10.2 and not 7.10.1 because 7.10.2 had some signifcant fixes for these kinds of issues. I'm certainly using GHC 7.10.2. --Kazu

GHC 7.10 complie time regression

Hi, I found that the compile time of GHC 7.10 against specific packages gets much longer than previous versions. Here is example: https://travis-ci.org/kazu-yamamoto/iproute/builds/77427248 On my local MacBook Air, I see the same phenomena: GHC 7.8: cabal build 8.81s user

Re: behavior change of the pretty printer

Thomas, Yes, it is intentional. See https://ghc.haskell.org/trac/ghc/ticket/2530 Thank you for this information. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

DynFlags.hs

Hi, I cannot build GHC 7.10.1 on CentOS 6.5 whose memory is just 1G. This is because compiler/main/DynFlags.hs is huge. It would be nice if this file could be split. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org

traverse_

Hi, I have just installed GHC 7.10.1. I'm a little bit surprised because 'traverse_' is not exported from Prelude. But 'traverse' is exported. Is this intentional? I expected that I can forget xxxM, xxxM_, xxxA, and xxxA_ functions with GHC 7.10.1. I want to use 'traverse_' instead of 'mapM_'.

Re: GHC with cabal-install

Hi Jack, I can't provide any guidance on what GHC might do, but I can from what other distributions have done. On both my Debian and Gentoo systems, there is a cabal-install package that is as easy to install as ghc. Perhaps CentOS could provide a similar package. I see that Fedora has a

Re: GHC with cabal-install

Hi Brandon, Too many additional dependencies. OK. Note that https://www.haskell.org/cabal/download.html *does* provide binary packages, specifically to address this. Oh. I did not know this page. Excellent. Thanks! --Kazu ___ ghc-devs mailing

Re: Behavior change of Data.Char

David, Thank you for the information. I would like to know whether or not this behavior changes are intentional. If they are bugs, we need to fix them before releasing GHC 7.10.1. --Kazu 7.10 uses a newer version of Unicode, which could explain differences. On Thu, Feb 19, 2015 at 12:19

Make one-shot a per-registration property

Hi, This is just confirmation. Ben's one-shot patch (*1) is included in master but not included in the ghc-7.10 branch. Is this intentional? Is it supposed to be merged in GHC 7.12? (*1) 023439980f6ef6ec051f676279ed2be5f031efe6 https://phabricator.haskell.org/D347 --Kazu

the performance of IO manager in GHC 7.10.1rc2

Hi, As usual, I took benchmark of IO manager to check if preformance regression is introduced. Fortunately, I don't see any preformance regression. +RTS -Nx124816 - GHC7.8.4 81,413 153,478 270,178

Re: the performance of IO manager in GHC 7.10.1rc2

Bardur, Out of curiosity: What are the units for numbers in the table? Requests per second per core? Yes. reqs/s --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal for removing transformers dependency

Hi, I also hope that this is integrated into GHC 7.10. --Kazu Hello. I'm coming with a proposal for removing transformers dependency from ghc library. The reason for this proposal that it's not possible to build consistent environment where a modern libraries (that depend on a newer

Re: Proposal for removing transformers dependency

Alexander, I'm coming with a proposal for removing transformers dependency from ghc library. Big +1 from me. doctest is suffering from dependency hell because ghc lib depends on transformers. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

Perhaps the readers of this list could read the reddit comments and propose a way forward? I tried to compile orf-new on Mac (Yosemite). orf-new cannot be compiled even after git submodule update --init. After modifying some code (e.g. ASSERT macros), it still fails on CMM part. I think that

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

Hi, If I understand correctly, OverloadedRecordFields has not been merged yet. Are there any chances to merge it into GHC 7.10.1? --Kazu We are pleased to announce the first release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc1/ This includes the source

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

No, it is a big change and the merge window is closed now. This question was just asked on reddit: http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/ Greg, thank you for this info. But it is really disappointing. I was silent about this because it

Re: ghc HEAD can't validate with xcode 6 clang on OS X

Hi Carter, on OS X 10.9 if i do git clone --recursive git://git.haskell.org/ghc.git ghc-valifail cd ghc-valifail perl boot ./configure --with-gcc=clang # the with gcc bit isnt needed, but making it clearly pick up clang is the point ./validate --fast No problem on my OS X 10.9. The

Re: One-shot semantics in GHC event manager

Q: Since registerFd uses OneShot and threadWait uses registerFd, basic IO functions use OneShot by default. No changes from GHC 7.8.3. Do I understand correctly? That is the idea. That being said adding another variant of registerFd (which as far as I know has three users) for

Re: One-shot semantics in GHC event manager

Ben, Hmm, uh oh. Thanks for testing this. I'll try to reproduce this on my end. It looks like it shouldn't be so hard as even the single-threaded performance regresses drastically. Just to confirm, you are using the latest revision of D347? I used the following as you suggested:

Re: One-shot semantics in GHC event manager

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 benchmarking on my own hardware. If

Re: One-shot semantics in GHC event manager

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 repo. Actually I compared the latest

Re: One-shot semantics in GHC event manager

Ahh, yes. Sorry, I forgot you were on 7.8. Just pushed a new patch to the event-rework-squashed branch [1]. I believe that you are trying to merge your patches to GHC 7.8.4? If not, I will work on the GHC head branch. --Kazu ___ ghc-devs mailing

Re: One-shot semantics in GHC event manager

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 other hand, it's a pretty easy change to

Re: One-shot semantics in GHC event manager

Out of curiosity are these numbers from single runs or do you average? Run three times and took the middle in this time. What are the uncertainties on these numbers? Even on the Rackspace machines I was finding very large variances in my benchmarks, largely due to far outliers. I didn't

Re: One-shot semantics in GHC event manager

Hi Austin, You need to set the CPU into C0 using /dev/cpu_dma_latency. Here's a short paper with a program to show the way to do it[1]. This paper is what I'm looking for. Thanks! --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org

Re: One-shot semantics in GHC event manager

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 measured the performace of GHC head, 7.8.3 and

Re: One-shot semantics in GHC event manager

Austin, 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. --Kazu

Re: deriving Bits

Hi Simon, Can you give an example? GHC has no specific code for Bits as far as I know. Perhaps you are using GeneralisedNewtypeDeriving? You don't give enough context to say. Yes, I'm using GeneralisedNewtypeDeriving. So, my question should be: Are there any other classes which can be

Re: deriving Bits

Simon, As the GND documentation says, it works for ANY class. So we can't list them! Understand. Thanks. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

deriving Bits

Hi, Recently, I found that we can put Bits in deriving. I checked the GHC manual but it seems to me that this page does not cover Bits: https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/deriving.html Are there any other classes which can be automatically derived and are not listed

Huge space leak of GHC API 7.8.x?

Hi, Some guys reported to me that ghc-mod uses about 1G bytes on Mac and I can reproduce this. I tried to understand why ghc-mod uses such huge memory. I found that GHC API 7.8.x uses much more memory than GHC API 7.6.x. Attached two files demonstrate this: - A.hs -- Simple program

Re: GHC 7.8.3 release

Hi, I would like to the status of GHC 7.8.3, too. Thanks. --Kazu On 05/27/2014 10:06 AM, Austin Seipp wrote: Hello all, After a long week, I've finally gotten a little time to reply to emails, and I mainly have one question I'd like to ask. First, please direct your attention to this:

Re: HEADS-UP: Git submodule conversion imminent

Johan, Should be fixed in 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177. Thanks. validate is finished with new settings on Mac. :-) --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: HEADS-UP: Git submodule conversion imminent

Herbert, It's done! Thanks. I tried to build GHC HEAD on Mac. I did: % git clone git://git.haskell.org/ghc.git % cd ghc % ./sync-all get % CPUS=10 sh validate Unfortunately, I got the following errors: inplace/bin/ghc-stage1 -optc-m64

Re: clang warnings

Austin, I've already merged two changesets into 7.8.3 - https://github.com/ghc/ghc/commit/5f9e0bedc9b08b46619f8ed4d09f645d6ed4 and https://github.com/ghc/ghc/commit/fd4169f9caf6922e3e5ea9c31f497f7220fc62b8 - which add -Qunused-arguments to the C compiler invocation if the compiler is

Re: clang warnings

Hi Richard, Would this fix #9047? Yay! I believe so. But currently validate itself fails: for i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist-derivedconsta nts/header/platformConstants settings; do case $i in *.a) /usr/bin/install -c -m 644 $i

Re: clang warnings

Hi, I don't know whether or not this is new but it's worth sharing. To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 branch. Unfortunately, on my Mac, I saw many warnings which are not displayed with GHC 7.8.2: clang: warning: argument unused during compilation:

Re: Status updates

Hi, - Also, if you have spare hardware, please email Gabor Pali (or just email the list itself, or reply to this thread) if you're willing to donate, that would be awesome. Another Mac OS X target would be especially welcome, I think (my development machine is on loan right now), and I will

Re: GHC 7.8.3 release

Hi Austin, I ask this because my time to dedicate to GHC is a bit thin right now, so you must help me decide what's important! So please let me know - just a general vote in favor of doing it within some X timeframe (even 'real soon' or 'a week would be great') would be nice. Would you give

Re: clang warnings

Hi, Also I found that GHC 7.8.2 can compile yesod-bin but GHC 7.8.3 cannot: [ 1 of 10] Compiling GhcBuild ( GhcBuild.hs, dist/build/yesod/yesod-tmp/GhcBuild.o ) GhcBuild.hs:150:55: Couldn't match type ‘Phase’ with ‘Bool - Phase’ Expected type: [(String, Maybe (Bool -

clang warnings

Hi, To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 branch. Unfortunately, on my Mac, I saw many warnings which are not displayed with GHC 7.8.2: clang: warning: argument unused during compilation: '-fno-stack-protector' clang: warning: argument unused during compilation: '-D

Re: validate on Mavericks

Richard, I've posted this problem as #9047 (https://ghc.haskell.org/trac/ghc/ticket/9047), but I have no information to help you -- sorry! Thanks anyway. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org

validate on Mavericks

Hi, Many tests for validate on master fail on Mavericks. This is because clang produces some warnings. Here is an example: = AssocTyDef03(normal) 3519 of 3960 [0, 1649, 0] cd ./typecheck/should_fail '/Users/kazu/work/ghc/bindisttest/install dir/bin/ghc ' -fforce-recomp -dcore-lint

Re: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git

Hi Herbert, Thank you for your kind explanation! --Kazu Otoh, I can offer part of the motivation for using `git submodules` from my current point of view from the top of my head: - We already use Git submodules for half the sub-repos, using a mix of submodules and subtrees might

Re: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git

Hi Herbert, After a short conversion with Austin and Edward it appears that the sensible course of action with respect towards moving to a proper Git submodule set-up is to fold-in the 5 Git repos listed below (which btw are all GHC wired-in packages) directly into ghc.git (the same way

Re: 7.8.2 bugs and beyond

Helo, The 7.8.2 source tarball is here. I actually have most of the binaries ready, but I forgot to send this in advance: http://www.haskell.org/ghc/dist/7.8.2/ Please build when you get a chance. I'll probably go ahead and announce shortly to get the bugfix into peoples hands, and we

Re: Template Haskell of GHC 7.8

Hi, Adam told a solution which uses mkName: https://github.com/sol/doctest-haskell/issues/76 Unfortunately, I hit upon another issue of Template Haskell. I will ask a question in another mail. --Kazu Hi, The tests for doctest are not passed again with GHC 7.8: 17)

Re: Template Haskell of GHC 7.8 (again)

Hi, Yes: https://ghc.haskell.org/trac/ghc/ticket/8833 Austin is looking at this for the 7.8 release Thanks. I guess you meant: https://ghc.haskell.org/trac/ghc/ticket/8831 --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org

Template Haskell of GHC 7.8

Hi, The tests for doctest are not passed again with GHC 7.8: 17) Property.runProperty reports the values for which a property that takes multiple arguments fails expected: [False,0,\\] but got: [interactive:24:66:,\8216doctest_prop\8217 is not in the type environment at a reify,

Re: ANNOUNCE: GHC 7.8.1 Release Candidate 2

Hi Austin, We've closed approximately 45 tickets that people filed for RC1 in this release. Thank you for all the reports! Good work! We plan to make the final 7.8.1 release soon, and hope RC2 will be the last RC. So *please* test as much as possible; bugs are much cheaper if we find them

Re: RC2 release imminent

Hi Austin, The RC2 source distribution is here: http://www.haskell.org/ghc/dist/7.8.1-rc2/ To my quick test, the @rpath problem on Mac has been fixed. Thank you! --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org

Re: RC2 status

Hi, Let me know if there are any questions or more importantly if I've missed anything. Please don't forget #8266. One patch should be applied to Cabal lib. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org

Re: 7.8 branch is created, HEAD is now open, and a note on merges

Hello Herbert, Hello Kazu, ..as this is a Cabal issue, this needs to be handled upstream; could you please file an issue at https://github.com/haskell/cabal/issues/new Done. https://github.com/haskell/cabal/issues/1660 --Kazu ___

Re: 7.8 branch is created, HEAD is now open, and a note on merges

Austin, Blargh, I'll fix this shortly. Thanks Pali. Please do. I also hit upon this bug. I could build GHC head yesterday but not today. P.S. Even if this is fixed, validate does not work on my Mac recently due to a haddock problem of the xhtml library. Does anyone see this problem? --Kazu

Re: 7.8 branch is created, HEAD is now open, and a note on merges

Hi Mateusz, I'll try building now. What's the error? Not building but validate. validate stops due to an error from haddock in the xhtml library. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 7.8 branch is created, HEAD is now open, and a note on merges

Hi Austin, It seems to me that the patch for Cabal in ticket 8266 is still missing: https://ghc.haskell.org/trac/ghc/ticket/8266 diff --git a/Cabal/Distribution/Simple/GHC.hs b/Cabal/Distribution/Simple/GHC.hs index c7ea633..78cdcbb 100644 --- a/Cabal/Distribution/Simple/GHC.hs +++

Re: RC Status

Hi, For Mac, we should verify darchon's Cabal patch for dynamic linking in #8266. darchon's patch does not works well in my Mavericks. https://ghc.haskell.org/trac/ghc/ticket/8266 If you guys are Mac users, please test darchon's patch. Also, a problem exists in FreeBSD:

panic when compiling SHA

Hi, When I tried to build the SHA library with GHC head on on 32bit Linux, GHC head got panic. GHC 7.4.2 can build SHA on the same machine. Configuring SHA-1.6.1... Building SHA-1.6.1... Failed to install SHA-1.6.1 Last 10 lines of the build log (

Re: whats our timeline for 7.8 release?

Hi, many many folks are wondering about when 7.8 is going to hit RC officially. What are the bugs / blockers / etc that are left to deal with? We should at least aim to communicate whats going on instead of leaving folks wondering. Would somebody answer this question? I'm also wondering.

Re: build errors

btw, curiously, Clang seems happy to compile ASSERT (...) occurences in C files such as rts/STM.c which have several of those... Yes. Clang supports it according to my test. I don't know why this happens. --Kazu ___ ghc-devs mailing list

Re: __builtin___clear_cache

Hi, I was discussed this with Austin in private messages. He understand what's the source of this problem and will fix it. --Kazu On 2013-11-29 at 03:37:43 +0100, Kazu Yamamoto (山本和彦) wrote: 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced __builtin___clear_cache. I think this is GCC

Re: Building GHC head with clang on Mavericks

Hi Simon, I think he has forgotten, yes. But yeah do send the pull requests anyway, my last set got merged in. Done: https://github.com/simonmar/happy/pull/13 https://github.com/simonmar/alex/pull/38 I've merged these and made new releases of Happy (1.19.2) and Alex (3.1.3).

Re: build errors

Hi, I cannot build GHC head on Linux and Mac (Mavericks) today: compiler/typecheck/TcEvidence.lhs:152:16: Not in scope: data constructor `ASSERT2' The attached patches are necessary to build GHC head on Mavericks. --Kazu diff --git a/compiler/coreSyn/CoreUtils.lhs

__builtin___clear_cache

Hi, 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced __builtin___clear_cache. I think this is GCC specific. So, Storage.c cannot be compiled with clang: rts/sm/Storage.c:1294:3: error: use of unknown builtin '__builtin___clear_cache' [-Wimplicit-function-declaration]

build errors

Hi, I cannot build GHC head on Linux and Mac (Mavericks) today: compiler/typecheck/TcEvidence.lhs:152:16: Not in scope: data constructor `ASSERT2' compiler/typecheck/TcEvidence.lhs:174:5: Not in scope: data constructor `ASSERT2' compiler/typecheck/TcEvidence.lhs:489:15: Not in

Cannot instantiate unification variable

Hi, Recent GHC head on 32bit Linux cannot build conduit-1.0.9.2. (See the attached log.) A while ago, GHC head on 32bit Linux could build it. The same GHC head on 64bit Linux can build it. Michael Snoyman suggested me to add ImpredicativeTypes. When I added it to the Internal.hs, GHC head on

clang/wrapper cannot build GHC head with integer-gmp on Mavericks

Hi, I'm try to make GHC head stably buildable with clang/wrapper on Mavericks because we cannot ask all Mavericks users to install apple-gcc or GCC. The last big item for me is integer-gmp. GHC head cannot be built with clang/wrapper if integer-gmp is used. (integer-simple is OK.) This is

Re: clang/wrapper cannot build GHC head with integer-gmp on Mavericks

are you sure gmp/ghc.mk is removed? After all, it's a file checked into Git: Oh. Probably I was confused. So, should we introduce a hack for Mavericks to gmp/ghc.mk? --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org

Re: clang/wrapper cannot build GHC head with integer-gmp on Mavericks

Hi, Oh. Probably I was confused. So, should we introduce a hack for Mavericks to gmp/ghc.mk? OK. I created a patch: https://ghc.haskell.org/trac/ghc/ticket/8497#comment:8 With this patch, I can build GHC head/integer-gmp with GHC 7.6.3/clang-wrapper on Mavericks/XCode 5. (Note that

Re: Building GHC head with clang on Mavericks

Hi, Kazu, can you put create pull requests for happy and alex with your required changes? I have one concern. The version of alex on Hackage is 3.1.2. But that of github is 3.1.1: https://github.com/simonmar/alex/blob/master/alex.cabal # This inconsistency exists in happy, too. Did

Re: Building GHC head with clang on Mavericks

I think he has forgotten, yes. But yeah do send the pull requests anyway, my last set got merged in. Done: https://github.com/simonmar/happy/pull/13 https://github.com/simonmar/alex/pull/38 --Kazu ___ ghc-devs mailing list

Re: Building GHC head with clang on Mavericks

Hi, so what are you proposing? I'm not proposing anything. I just want to share information so that we can find a good solution. Are you agreeing that those patches work with clang wrapper, but also remarking that its unfortunate that such a hack is needed? As I said, nkpart's patches are

Re: Building GHC head with clang on Mavericks

Was there an issue if you used a wrapped clang and those patches or not? I'm really confused. Even with GHC/clang-wrapper and alex/happy with Nick's patches, I cannot build GHC head. (I'm not using GCC 42 at all in this case.) AlexTemplate (pre-processed by clang) has linemarkers like this:

Re: Building GHC head with clang on Mavericks

Hi Carter, Nick Partridge hit this recently and he's got PR's pending for Happy and Alex https://github.com/simonmar/alex/pull/37 and https://github.com/simonmar/happy/pull/12 I'm not using GCC. (In my previous message, I made a typo. GCC should be read as clang). So, I think that this is a

Re: Building GHC head with clang on Mavericks

Hi, Adding the -v option, GHC displays: *** Checking old interface for main:Lexer: *** Parser: *** Renamer/typechecker: built-in:2:2: Not in scope: `#' -keep-tmp-files keeps generated .hscpp file. The beginning of the generated .hscpp is: # 1

Re: Building GHC head with clang on Mavericks

Hi, I can finally build GHC head on Mavericks. I gave up on clang and installed GHC 4.8 with MacPorts. Then, I compiled alex and happy with GHC 7.6.3/GHC 4.8. With this, I can build GHC head. This step is a MUST. If alex and happy are complied GHC 7.6.3/clang-wrapper, I cannot build GHC head

Building GHC head with clang on Mavericks

Hi, As I wrote in the following blog article, I could build GHC head on Mavericks 20 days ago. http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924 But I cannot build it recently: /usr/bin/ghc -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db

Re: Wither Haskell Platform 2013.4.0.0

Hi, What change did we think we need for a GHC 7.6.4 to support Xcode 5? Was it just this change to fiddle with the command line options? I don't know what is the best. But here is what I know now: clang-xcode5-wrapper.hs (*1) works as a wrapper in many cases so far. We need to change the

XCode 5

Hi all, To check ticket #8139, I'm wondering whether or not I should install XCode 5 to my MacBook Air. I heard that GCC will be removed if XCode 5 is installed. I also heard that if we modify lib/settings of GHC 7.6.3, GHC 7.6.3 can work with clang. So, my question: how can I build GHC head

Re: #8276

Andi, Is there a workaround for http://ghc.haskell.org/trac/ghc/ticket/8276. I haven't been able to build HEAD for a while due to this issue. Put the following one line to your mk/build.mk. HADDOCK_DOCS = NO The entire contents of my build.mk is: InstallExtraPackages = YES

Re: Haddock is broken in head?

Hi Páli, Please read: http://ghc.haskell.org/trac/ghc/ticket/8276 --Kazu Hi there, I have been recently experiencing some problems with haddock in head on FreeBSD, spotted by both of my builder clients [1,2], but quite reproducible on a recent FreeBSD system too: [snip]

build failures on Linux

Hi, I cannot build GHC head today on Linux. It seems to me that this bug is relating to the followings: https://github.com/sol/doctest-haskell/issues/59 https://github.com/sol/doctest-haskell/pull/60 Why did the initial value of v_opt_C_ready in GHCI change? --Kazu Haddock

Re: A bug of linebuffering

Hi, I found a workaround for this problem. https://github.com/sol/doctest-haskell/issues/57 --Kazu Hi, While I support GHC head for doctest, I encountered the following bug. doctest uses a GHCi subprocess to evaluate an expression represented in String. Stderr from GHCi is

Dynamic libraries on Mac

Hi, I built GHC head today (with d61c3ac186c94021c851f7a2a6d20631e35fc1ba reverted). While I'm supporting GHC head for doctest on Mac, I found the following problems relating to dynamic linking: (1) Every .dylib installed with GHC head refers to itself in its build directory. E.g. %

Re: A build problem on Mac

Hi, Thanks Kazu! This should get me going. Can you temporarily work with my commit reverted? Yes. I got this log without reverting. And now I'm using GHC head with your commit reverted. It's interesting that this time you got failure for a different file than in your original email to the

A bug of linebuffering

Hi, While I support GHC head for doctest, I encountered the following bug. doctest uses a GHCi subprocess to evaluate an expression represented in String. Stderr from GHCi is merged into stdout by hDuplicateTo in the GHCi side. Even evaluating an error expression, for instance 1 `div` 0, the

Re: 7.8 Release Update

Hi, Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug? I'm not completely sure yet. GHCi 7.8 uses dynamic linking. This is true. So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they supposed to use dynamic

Re: A build problem on Mac

Hi, I believe this is related to http://ghc.haskell.org/trac/ghc/ticket/8205 - can you try: $ git revert d61c3ac186c94021c851f7a2a6d20631e35fc1ba and see if your build finishes? Perhaps you can help Jan diagnose it if so... Yes. After this command, I can build GHC head on Mac. --Kazu

  1   2   >