Re: Can't install packages with my inplace compiler
On Tue, 2014-11-04 at 21:04 +, Simon Peyton Jones wrote: | Yeah, that's too old; and there's not been a release of a Cabal | which is new enough to do what you want. Wow! I'm doing the most basic thing: using Cabal to install a package with a specified GHC. I'll try what you suggest. Actually I'd suggest you use the Cabal and cabal-install that are part of the ghc source tree, rather than Cabal/cabal-install HEAD. The two are not always the same. We try to avoid getting into situations where older cabal binaries cannot use the current ghc, but it does happen sometimes when we make changes in ghc that are not fully backwards compatible. In this case we (or rather I) removed ghc's support for single-file style package dbs and we later discovered that Cabal was in one place still using that style. It's plausible that we might want to add back some hack to ghc-pkg to allow older Cabal versions to work with ghc head. So in this situation we have to use the Cabal library (that you built with ghc head), to build cabal-install and its dependencies in the old style, using Setup.hs. That'll also need the dev version of zlib, due to the AMP things. Duncan: would a release be a good plan? We tend not to make intermediate releases to support ghc head because when we're making changes to work with ghc head we're not always in a good spot to make releases for the general public (we tend to be in the middle of things and not have enough testing feedback). Also, people using ghc head already have the corresponding version of Cabal/cabal-install in their source tree which they can install and use. On the other hand, when we think we're in a reasonable state with Cabal testing, and ghc is getting into release mode and we have more people needing to test ghc head, then of course making a release becomes important. My point is that when Edward and I were making all these breaking changes to Cabal/ghc in the packaging area is exactly the wrong time to make a cabal release. In this situation we just have to tell ghc hackers to use the Cabal/cabal-install from the ghc tree. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Can't install packages with my inplace compiler
| Actually I'd suggest you use the Cabal and cabal-install that are part | of the ghc source tree, rather than Cabal/cabal-install HEAD. The two | are not always the same. Aha ok, thank you. How exactly do I do that? Where is the executable cabal-install in the tree? IN inplace/bin I see an executable ghc-cabal. Is that it? Alternatively, Plan B on https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace (which I confess I'd forgotten about) describes a different plan that doesn't mention cabal-install at all. Is that better? Thanks Simon | -Original Message- | From: Duncan Coutts [mailto:dun...@well-typed.com] | Sent: 05 November 2014 09:41 | To: Simon Peyton Jones | Cc: Edward Z. Yang; Herbert Valerio Riedel; GHC Devs | Subject: Re: Can't install packages with my inplace compiler | | On Tue, 2014-11-04 at 21:04 +, Simon Peyton Jones wrote: | | Yeah, that's too old; and there's not been a release of a Cabal | | which is new enough to do what you want. | | Wow! I'm doing the most basic thing: using Cabal to install a | package with a specified GHC. | | I'll try what you suggest. | | Actually I'd suggest you use the Cabal and cabal-install that are part | of the ghc source tree, rather than Cabal/cabal-install HEAD. The two | are not always the same. | | We try to avoid getting into situations where older cabal binaries | cannot use the current ghc, but it does happen sometimes when we make | changes in ghc that are not fully backwards compatible. In this case | we (or rather I) removed ghc's support for single-file style package | dbs and we later discovered that Cabal was in one place still using | that style. It's plausible that we might want to add back some hack to | ghc-pkg to allow older Cabal versions to work with ghc head. | | So in this situation we have to use the Cabal library (that you built | with ghc head), to build cabal-install and its dependencies in the old | style, using Setup.hs. That'll also need the dev version of zlib, due | to the AMP things. | | Duncan: would a release be a good plan? | | We tend not to make intermediate releases to support ghc head because | when we're making changes to work with ghc head we're not always in a | good spot to make releases for the general public (we tend to be in | the middle of things and not have enough testing feedback). Also, | people using ghc head already have the corresponding version of | Cabal/cabal-install in their source tree which they can install and | use. | | On the other hand, when we think we're in a reasonable state with | Cabal testing, and ghc is getting into release mode and we have more | people needing to test ghc head, then of course making a release | becomes important. | | My point is that when Edward and I were making all these breaking | changes to Cabal/ghc in the packaging area is exactly the wrong time | to make a cabal release. In this situation we just have to tell ghc | hackers to use the Cabal/cabal-install from the ghc tree. | | -- | Duncan Coutts, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
As part of #9358 I'm considering removing these two flags: -ddump-simpl-phases: dumps simplifier statistics for phases of the simplifier but it works only when used together with -ddump-simpl-stats. User can limit which statistics are displayed by passing in either the simplifier phase number (0,1,2), phase name (final, main, post-worker-wrapper, Gentle) or both (separated with :). So for example -ddump-simpl-phases=0:main,1 dumps statistics for all pases labeled as phase 1 and only those pases of phase 0 that are named main. Has anyone ever used that flag? Do we consider it useful? -ddump-core-pipeline: this seems like a partially implemented stub. The name is very misleading because it is related to plugins. The only thing that it seems to do at the moment is that when -ddump-to-file is set then -ddump-core-pipeline will result in dumping plugin passes to file. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
package 'categories' fails with HEAD
Hi all, some time ago I filed: https://github.com/ekmett/categories/issues/4 against the 'categories' library. But I cannot see what is wrong with the code. It also builds with older GHCs (though I should re-check with 7.8.3). So I conjecture this is a HEAD problem in GHC HEAD. It seems weird. Any ideas what this could be? Cheers, Gabor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Msys2-users] Debugging undeterministic segfaults
Sorry for the large amount of messages. On 5. 11. 2014 8:01, David Macek wrote: I'm running validate to double check (detected 4 CPUs). I got the validate results: Unexpected results from: TEST=linker_unload listCommand002 T5681 T5486 T7571 ghcpkg05 T3924 T7702 plugins01 T6106 ghci038 T8172 ghci032 T5975a T5975b ghci058 T3064 T3307 environment001 T876 T3738 T4830 T5205 T7436 lazy-bs-alloc T1407 rdynamic T7037 T5423 T8124 T5435_dyn_asm prog012 prog013 prog001 prog002 prog003 T4006 OVERALL SUMMARY for test run started at 11/05/14 09:04:01 Central Europe Standard Time 1:01:50 spent to go through 4095 total tests, which gave rise to 14911 test cases, of which 11167 were skipped 58 had missing libraries 3578 expected passes 71 expected failures 1 caused framework failures 1 unexpected passes 36 unexpected failures Unexpected passes: rts linker_unload (normal) Unexpected failures: ../../libraries/base/tests T4006 [bad stdout] (normal) ../../libraries/base/tests/IO T3307 [bad exit code] (normal) ../../libraries/base/tests/IO environment001 [bad stdout] (normal) cabal ghcpkg05 [bad stderr] (normal) callarity/perf T3924 [stat too good] (normal) ghci.debugger/scripts listCommand002 [bad stderr] (ghci) ghci/linking T1407 [bad stderr] (ghci) ghci/prog001 prog001 [bad stderr] (ghci) ghci/prog002 prog002 [bad stderr] (ghci) ghci/prog003 prog003 [bad exit code] (ghci) ghci/prog012 prog012 [bad stderr] (ghci) ghci/prog013 prog013 [bad stderr] (ghci) ghci/scripts T5975a [bad stderr] (ghci) ghci/scripts T5975b [bad stderr] (ghci) ghci/scripts T6106 [bad stderr] (ghci) ghci/scripts T8172 [bad stdout] (ghci) ghci/scripts ghci032 [bad stderr] (ghci) ghci/scripts ghci038 [bad stderr] (ghci) ghci/scripts ghci058 [bad stderr] (ghci) llvm/should_compileT5486 [stderr mismatch] (optllvm) llvm/should_compileT5681 [stderr mismatch] (optllvm) llvm/should_compileT7571 [stderr mismatch] (optllvm) perf/compiler T3064 [stat not good enough] (normal) perf/should_runT3738 [stat too good] (normal) perf/should_runT4830 [stat too good] (normal) perf/should_runT5205 [stat too good] (normal) perf/should_runT7436 [stat too good] (normal) perf/should_runT876 [stat not good enough] (normal) perf/should_runlazy-bs-alloc [stat not good enough] (normal) pluginsplugins01 [bad stderr] (normal) rtsT5423 [bad stdout] (normal) rtsT5435_dyn_asm [bad stdout] (normal) rtsT7037 [bad stdout] (normal) rtsT8124 [exit code non-0] (threaded1) rtsrdynamic [bad exit code] (normal) simplCore/should_compile T7702 [stderr mismatch] (normal) I assume that means the build itself had no errors. -- David Macek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
I don't use either, so fine with me! | -Original Message- | From: Jan Stolarek [mailto:jan.stola...@p.lodz.pl] | Sent: 05 November 2014 10:12 | To: ghc-devs@haskell.org | Cc: Simon Peyton Jones | Subject: Removing -ddump-simpl-phases and -ddump-core-pipeline flags? | | As part of #9358 I'm considering removing these two flags: | | -ddump-simpl-phases: dumps simplifier statistics for phases of the | simplifier but it works only | when used together with -ddump-simpl-stats. User can limit which | statistics are displayed by | passing in either the simplifier phase number (0,1,2), phase name (final, | main, | post-worker-wrapper, Gentle) or both (separated with :). So for | example -ddump-simpl-phases=0:main,1 dumps statistics for all pases | labeled as phase 1 and only | those pases of phase 0 that are named main. Has anyone ever used that | flag? Do we consider it | useful? | | -ddump-core-pipeline: this seems like a partially implemented stub. The | name is very misleading | because it is related to plugins. The only thing that it seems to do at | the moment is that | when -ddump-to-file is set then -ddump-core-pipeline will result in | dumping plugin passes to | file. | | Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can't install packages with my inplace compiler
Hmmm, is this cabal mess the reason for the problems with GHC head and Cabal head on https://travis-ci.org/haskell-opengl/StateVar/jobs/39533455#L102? I've brought up the problem in another thread, but there was no conclusion. As it is, there seems to be no way to test things with GHC head on Travis CI, which is really bad. :-/ What can be done here? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Hidden LLVM flags
DynFlags list some LLVM flags as hidden: ( llvm-tbaa,Opt_LlvmTBAA, nop), -- hidden flag ( llvm-pass-vectors-in-regs,Opt_LlvmPassVectorsInRegisters, nop), -- hidden flag Do I undertsand correctly that hidden means not documented in the User's Guide? Is there a good reason for this? I'd like to document them as part of #9358, especially that -fllvm-tbaa is enabled by default for all optimisation levels. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Hidden LLVM flags
I found this note in CmmCallConv: -- On X86_64, we always pass 128-bit-wide vectors in registers. On 32-bit X86 -- and for all larger vector sizes on X86_64, LLVM's GHC calling convention -- does not currently pass vectors in registers. The patch to update the GHC -- calling convention to support passing SIMD vectors in registers is small and -- well-contained, so it may make it into LLVM 3.4. The hidden -- -fllvm-pass-vectors-in-regs flag will generate LLVM code that attempts to -- pass vectors in registers, but it must only be used with a version of LLVM -- that has an updated GHC calling convention. What's the status? Is this patch present in LLVM 3.4? As a side note I'm puzzled by the implementation: passVectorInReg :: Width - DynFlags - Bool passVectorInReg W128 dflags = case platformArch (targetPlatform dflags) of ArchX86_64 - True _ - gopt Opt_LlvmPassVectorsInRegisters dflags passVectorInReg _dflags = gopt Opt_LlvmPassVectorsInRegisters dflags It seems that by enabling -fllvm-pass-vectors-in-regs I can change the calling convention for vectors of any length other than 128 bits. Janek Dnia środa, 5 listopada 2014, Jan Stolarek napisał: DynFlags list some LLVM flags as hidden: ( llvm-tbaa,Opt_LlvmTBAA, nop), -- hidden flag ( llvm-pass-vectors-in-regs,Opt_LlvmPassVectorsInRegisters, nop), -- hidden flag Do I undertsand correctly that hidden means not documented in the User's Guide? Is there a good reason for this? I'd like to document them as part of #9358, especially that -fllvm-tbaa is enabled by default for all optimisation levels. Janek ___ 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: GHC AST Annotations (again)
I have placed an ordering on it so that D426 comes first, then D438 and finally D412, there was a very minor merge update required for D412. On Tue, Nov 4, 2014 at 11:41 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: Hi all Hopefully I will be able to stop harassing everyone on this topic soon. The final versions of the patches for this are ready for review. It has been split into three parts D412 Extends the HsLit values to have an extra field for the original source text, which can differ from the literal value. D426 adds various extra locations in the HsSyn AST to allow the additions of API annotations everywhere needed. D438 modifies the Lexer/Parser to produce API annotations and comments as part of the ParsedSource result. Please review if you are interested. Links https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations https://ghc.haskell.org/trac/ghc/ticket/9628 https://phabricator.haskell.org/D412 https://phabricator.haskell.org/D426 https://phabricator.haskell.org/D438 Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Tests with compilation errors
I skimmed Austin's message again and then began the hunt from the main wiki page. I ended up with these open tabs: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries#Classifyingbootpackages https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Details Nothing jumped out at me as just the right spot. The main mismatch seems to be the motivation of the text; Austin's message had more of this is why it is the way it is than I see on the wiki. Also, I didn't notice any mention of the details that Austin gave about validate.sh. HTH On Fri, Oct 31, 2014 at 3:25 AM, Simon Peyton Jones simo...@microsoft.com wrote: Nick, Where in the wiki would you have looked for it? This isn’t at trick question. It’s quite hard to know where to record info! S *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Nicolas Frisby *Sent:* 30 October 2014 22:42 *To:* Austin Seipp *Cc:* ghc-devs@haskell.org *Subject:* Re: Tests with compilation errors This reply is very informative! Could you put it on the wiki for me to digest at a later date? (Or maybe there's already a consolidated place to find it all on there?) Thanks very much for sharing all of this. On Thu, Oct 30, 2014 at 2:19 PM, Austin Seipp aus...@well-typed.com wrote: On Thu, Oct 30, 2014 at 6:48 AM, Gintautas Miliauskas gintautas.miliaus...@gmail.com wrote: Going through some validate.sh results, I found compilation errors due to missing libraries, like this one: = stm052(normal) 4088 of 4108 [0, 21, 0] cd ../../libraries/stm/tests 'C:/msys64/home/Gintas/ghc/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopt s -fno-warn-tabs -fno-ghci-history -o stm052 stm052.hs -package stm stm052.comp.stderr 21 Compile failed (status 256) errors were: stm052.hs:10:8: Could not find module ‘System.Random’ Use -v to see a list of the files searched for. I was surprised to see that these are not listed in the test summary at the end of the test run, but only counted towards the X had missing libraries row. That setup makes it really easy to miss them, and I can't think of a good reason to sweep such tests under the rug; a broken test is a failing test. Actually, these tests aren't broken in the way you think :) It's a bit long-winded to explain... Basically, GHC can, if you let it, build extra dependencies in its build process, one of which is the 'random' library. 'random' was not ever a true requirement to build GHC (aka a 'bootlib' as we call them). So why is this test here? Because 'random' was actually a dependency of the Data Parallel Haskell package, and until not too long ago (earlier this year), `./validate` built and compiled DPH - with all its dependencies; random, vector, primitive - by default. This actually adds a pretty noticeable time to the build (you are compiling 5-8 more libraries after all), and at the time, DPH was also not ready for the Applicative-Monad patch. So we turned it off, as well as the dependencies. Additionally, GHC does have some 'extra' libraries which you can optionally build during the build process, but which are turned off by default. Originally this was because the weirdo './sync-all' script used to not need everything, and 'stm' was a library that wasn't cloned by default. Now that we've submoduleified everything though, these tests and the extra libraries could be built by default. Which we could certainly do. How about at least listing such failed tests in the list of failed tests of the end? I'd probably be OK with this. At least in this case the error does not seem to be due to some missing external dependencies (which probably would not be a great idea anyway...). The test does pass if I remove the -no-user-package-db argument. What was the intention here? Does packaging work somehow differently on Linux? (I'm currently testing on Windows.) I'm just guessing but, I imagine you really don't want to remove '-no-user-package-db' at all, for any platform, otherwise Weird Things Might Happen, I'd assume. The TL;DR here is that when you build a copy of GHC and all the libraries, it actually *does* register the built packages for the compiler... this always happens, *even if you do not install it*. The primary 'global' package DB just sits in tree instead, under ./inplace. When you run ./validate, what happens is that after the build, we actually create a binary distribution and then test *that* compiler instead, as you can see (obviously for a good reason - broken bindists would be bad). The binary distribution obviously has its own set of binary packages it came with; those are the packages you built into it after all. The reason we tell GHC to
Re: Problems compiling with llvm-3.5.0-2 on ARM
TL;DR, you cant use llvm 3.5 or 3.6 with any current ghc release. use 3.4 or older On Tue, Nov 4, 2014 at 10:56 PM, Jens Petersen juhpeter...@gmail.com wrote: Hi Jarl, I think I just ran into this too for Fedora 22 rawhide on ARM and found your posts... On 30 October 2014 16:11, Jarl Gunnar Flaten jarl.fla...@gmail.com wrote: (cf. reddit thread http://www.reddit.com/r/haskell/comments/2kpsz5/ghc_problem_new_llvm_schedule_reentered_unsafely/ ) I am trying to compile a simple hello world program (test.hs). When compiling I am notified: [1 of 1] Compiling Main ( test.hs, test.o ) You are using a new version of LLVM that hasn't been tested yet! test: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? Isn't working. I'm not familiar enough with neither LLVM nor Haskell to troubleshoot from either of these; I don't even know if the messages are even related. They are related in the sense that llvm-3.5 seems to this problem and it is not officially supported by ghc-7.6 or ghc-7.8 (hence the warning). ghc-7.8 supports 3.4 and 7.6 seems to mostly work with some patches. Can you provide more details on your environment: OS and ghc version etc? I am not sure yet what is causing this: perhaps you could try compiling with -threaded and see if that helps? Jens ___ 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: [Msys2-users] Debugging undeterministic segfaults
Thanks for pointing out that virus scanners could be an issue. I found that Microsoft Security Essentials realtime scanning was on. I'll try disabling it and see if that helps with the -j5 case. For what it's worth, I tried disabling the virus scanner, but it did not help, 4/8 validation runs segfaulted (-j5). -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can't compile GHC-7.8.3 from git, fails on haskell98 library
Starting with GHC 7.8.x, fingerprints are written into annotated gpg-signed release tags: http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release That way you're able to restore via the fingerprint for a given release via: ./utils/fingerprint/fingerprint.py restore -f (git show ghc-7.8.3-release | grep -F '|') I'm just surprised I couldn't find that described anywhere in the wiki, I was sure it was written down somewhere... Oh, pretty useful. I also couldn't find it on the wiki and this page https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization even claims it's going to be obsolete (starting with 7.10?). Google shows that something related was mentioned in https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources?version=93 but the new version of the page missed that info. This emails refers to the no-longer available info on the wiki, too: https://www.haskell.org/pipermail/ghc-devs/2014-January/003930.html I wonder what happened and which info is meaningful only for GHC 7.8 or even ==7.8 and which parts make sense for 7.10 as well. Cheers, Mikolaj ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
Yep, I say remove them both. On Wed, Nov 5, 2014 at 4:57 AM, Simon Peyton Jones simo...@microsoft.com wrote: I don't use either, so fine with me! | -Original Message- | From: Jan Stolarek [mailto:jan.stola...@p.lodz.pl] | Sent: 05 November 2014 10:12 | To: ghc-devs@haskell.org | Cc: Simon Peyton Jones | Subject: Removing -ddump-simpl-phases and -ddump-core-pipeline flags? | | As part of #9358 I'm considering removing these two flags: | | -ddump-simpl-phases: dumps simplifier statistics for phases of the | simplifier but it works only | when used together with -ddump-simpl-stats. User can limit which | statistics are displayed by | passing in either the simplifier phase number (0,1,2), phase name (final, | main, | post-worker-wrapper, Gentle) or both (separated with :). So for | example -ddump-simpl-phases=0:main,1 dumps statistics for all pases | labeled as phase 1 and only | those pases of phase 0 that are named main. Has anyone ever used that | flag? Do we consider it | useful? | | -ddump-core-pipeline: this seems like a partially implemented stub. The | name is very misleading | because it is related to plugins. The only thing that it seems to do at | the moment is that | when -ddump-to-file is set then -ddump-core-pipeline will result in | dumping plugin passes to | file. | | Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
precedence when printing context patch breaks ghc-7.8 branch
Hi, A build of the ghc-7.8 branch in its current state failed for me today in compiler/types/TypeRep.lhs I am at commit 7b1d4c4 (release note blurb...), there was only one more since (revert 'revert'...). It seems as though the merge of commit d71f316ef (...precedence when printing contexts..) does not fit into ghc-7.8 (that patch works on HEAD, of course). Error message is: compiler/types/TypeRep.lhs:540:35: Not in scope: data constructor `TyOpPrec' (a constructor introduced by that patch) I have no idea how to fix this (GHC itself suggests TopPrec, but that actually reverts the fix :-) ) Cheers, Jost Berthold ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: precedence when printing context patch breaks ghc-7.8 branch
Gah, sorry about that. I'll fix it! On Wed, Nov 5, 2014 at 2:31 PM, Jost Berthold berth...@mathematik.uni-marburg.de wrote: Hi, A build of the ghc-7.8 branch in its current state failed for me today in compiler/types/TypeRep.lhs I am at commit 7b1d4c4 (release note blurb...), there was only one more since (revert 'revert'...). It seems as though the merge of commit d71f316ef (...precedence when printing contexts..) does not fit into ghc-7.8 (that patch works on HEAD, of course). Error message is: compiler/types/TypeRep.lhs:540:35: Not in scope: data constructor `TyOpPrec' (a constructor introduced by that patch) I have no idea how to fix this (GHC itself suggests TopPrec, but that actually reverts the fix :-) ) Cheers, Jost Berthold ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: precedence when printing context patch breaks ghc-7.8 branch
Thanks Jost; I somehow totally missed this and reverted it (I'll look into fixing it properly shortly). On Wed, Nov 5, 2014 at 2:35 PM, Austin Seipp aus...@well-typed.com wrote: Gah, sorry about that. I'll fix it! On Wed, Nov 5, 2014 at 2:31 PM, Jost Berthold berth...@mathematik.uni-marburg.de wrote: Hi, A build of the ghc-7.8 branch in its current state failed for me today in compiler/types/TypeRep.lhs I am at commit 7b1d4c4 (release note blurb...), there was only one more since (revert 'revert'...). It seems as though the merge of commit d71f316ef (...precedence when printing contexts..) does not fit into ghc-7.8 (that patch works on HEAD, of course). Error message is: compiler/types/TypeRep.lhs:540:35: Not in scope: data constructor `TyOpPrec' (a constructor introduced by that patch) I have no idea how to fix this (GHC itself suggests TopPrec, but that actually reverts the fix :-) ) Cheers, Jost Berthold ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Update Trac link 'Patches for review'
Dear Trac admins, on the left panel of the Trac wiki there is a link https://ghc.haskell.org/trac/ghc/query?status=patchol=idcol=summarycol=ownercol=typecol=prioritycol=milestonecol=componentorder=priority called 'Patches for review'. This shows a mix of tickets that have patches attached, and tickets that are being reviewed on Phabricator. Can someone change that link to only show the tickets that have patches attached, such that those are more easily found? You can do this by appending differential= to the url. The list of open Phabricator reviews https://phabricator.haskell.org/differential/ can be discovered on the Phabricator homepage, but I'm afraid the tickets https://ghc.haskell.org/trac/ghc/query?status=patchdifferential=col=idcol=summarycol=ownercol=typecol=prioritycol=milestonecol=componentorder=priority that have patches attached are now sometimes overlooked. Thanks, Thomas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building head with head
Hello Moritz, I tried to do this relatively recently and recorded the problems here: https://ghc.haskell.org/trac/ghc/ticket/9652 I didn't finish diagnosing the further error. Edward Excerpts from Moritz Angermann's message of 2014-11-04 10:28:18 -0800: Hi, today I tried to build head with head on os x. The result was: Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ... touch utils/ghc-cabal/dist/build/tmp/ghc-cabal cp utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal inplace/bin/ghc-cabal configure libraries/binary dist-boot --with-ghc=/usr/local/bin/ghc --with-ghc-pkg=/usr/local/bin/ghc-pkg --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS= -m64 -fno-stack-protector--configure-option=LDFLAGS= -m64 --configure-option=CPPFLAGS= -m64 --gcc-options= -m64 -fno-stack-protector -m64 --constraint binary == 0.7.1.0 --constraint Cabal == 1.21.1.0 --constraint hpc == 0.6.0.2 --constraint bin-package-db == 0.0.0.0 --constraint hoopl == 3.10.0.2 --constraint transformers == 0.4.1.0 --constraint terminfo == 0.4.0.0 --with-gcc=/usr/bin/gcc --configure-option=--with-cc=/usr/bin/gcc --with-ar=/usr/bin/ar --with-alex=/Users/angerman/.cabal/bin/alex --with-happy=/Users/angerman/.cabal/bin/happy inplace/bin/ghc-cabal configure utils/hsc2hs dist --with-ghc=/usr/local/bin/ghc --with-ghc-pkg=/usr/local/bin/ghc-pkg --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --disable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS= -m64 -fno-stack-protector--configure-option=LDFLAGS= -m64 --configure-option=CPPFLAGS= -m64 --gcc-options= -m64 -fno-stack-protector -m64 --constraint binary == 0.7.1.0 --constraint Cabal == 1.21.1.0 --constraint hpc == 0.6.0.2 --constraint bin-package-db == 0.0.0.0 --constraint hoopl == 3.10.0.2 --constraint transformers == 0.4.1.0 --constraint terminfo == 0.4.0.0 --with-gcc=/usr/bin/gcc --configure-option=--with-cc=/usr/bin/gcc --with-ar=/usr/bin/ar --with-alex=/Users/angerman/.cabal/bin/alex --with-happy=/Users/angerman/.cabal/bin/happy Configuring hsc2hs-0.67... Configuring binary-0.7.1.0... ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/Users/angerman/code/ghc/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. make[1]: *** [utils/hsc2hs/dist/package-data.mk] Error 1 make[1]: *** Waiting for unfinished jobs ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/Users/angerman/code/ghc/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. make[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1 Does anyone know what needs to be done to make this work? Best, Moritz ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
loadInterfaceForModule
Hello Gergely, I was cleaning up LoadIface and I noticed in commit 69fa2e558d56178d33950df815c3233606b0d44e Author: Austin Seipp aus...@well-typed.com Date: Fri Nov 1 22:15:53 2013 -0500 Add support for module reification (#1480) Authored-by: Gergely Risko gerg...@risko.hu Signed-off-by: Austin Seipp aus...@well-typed.com You added a function loadInterfaceForModule which has the exact same type as loadModuleInterface, except when debugging is on it has an extra check to ensure you don't try to load the the current module (this seems like a general invariant that would be good to enforce). Was there any particular reason you created an extra function for this, or can we just use the existing function? Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
