Error messages
Hi all, Although it was many years ago I did spend soem time working on GHC and I do know what a thankless task it is. I made a compliant about GHC error messages on an internal Slack channel and Mortiz encouraged me to repeat it here. I am incredibly happy about the quality of error messges for older more standard parts of Haskell, probably most things in Haskell98 and Haskell2010. By way of contrast, error messages for some newer parts of Haskell are incredibly poor. In fact, for the new parts, the error rmessages are often wrong, just defaulting to error messages for older parts of Haskell. As an example (open source code in a public GH repo): src/Cardano/DbSync/StateQuery.hs:87:44: error: • Data constructor not in scope: QueryAnytime :: QueryHardFork xs0 (Interpreter xs0) -> Query (CardanoBlock TPraosStandardCrypto) (Interpreter (CardanoEras TPraosStandardCrypto)) • Perhaps you want to add ‘QueryAnytime’ to the import list in the import of ‘Ouroboros.Consensus.HardFork.Combinator.Ledger.Query’ (src/Cardano/DbSync/StateQuery.hs:49:1-116). | 87 | queryHistoryInterpreter connInfo (point, QueryAnytime GetInterpreter) The suggestion is that I need to import `QueryAnytime` but just 20 line above I have: import Ouroboros.Query (QueryAnytime (..), QueryHardFork (GetInterpreter)) The problem is that `QueryAnytime` is defined as a pattern synonym. I have only the tinest amount of experience using pattern synonyms and that error message is not really useful. I would like to suggest that a prerequesite for merging of new features would be that it provides good error messages and more importantly does not provide wrong or misleading error messages like the one above. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: libraries/array bad git hash?
Ben Gamari wrote: > From which repository are you trying to clone? I just cloned from the > upstream GitLab > repository without any trouble. I suspect you are cloning from a > stale repository as 58a7ea hasn't been the array commit referred to by > GHC's master branch for months now. Yep, fixed by cloning from: https://gitlab.haskell.org/ghc/ghc as per the documentation. Thanks Ben! Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
libraries/array bad git hash?
Hi all, I just tried to clone a new copy of the GHC sources and on pulling the submodules i get: Fetched in submodule path 'libraries/array', but it did not contain 58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that commit failed. I suspect that someone updated to that hash without pushing their changes to the public repo. Cheers, Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Removing Hoopl dependency?
Michal Terepeta wrote: > What do you think? Does anyone think we shouldn't do this? Makes sense. I'm +1 on this. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: make install fails on master on macOS Sierra
Mitsutoshi Aoe wrote: > Hi Erik, > > Thanks for the info. Is there a way to tell what version of Cabal was used > to build GHC? I actually don't think that's relevant. > I've tried the latest cabal-install from Hackage and from master on GitHub > with no luck. Either of those should be fine. > Also the Cabal git submodule in the GHC checkout is pointed to 41f416bc2, > which seems to be Cabal-2.0.0.0. That is correct (and also not relevant). Since you are using the correct version of cabal, my guess at the problem being with the version of cabal is almost certainly wrong. At this point I would suggest doing a "make clean", then running the bootstrap script and configure again before rebuilding. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: make install fails on master on macOS Sierra
Mitsutoshi Aoe wrote: > I'm trying to build recent master (579bb766) on macOS Sierra but make install > fails as follows: > > "/usr/local/ghc/ghc-HEAD/lib/ghc-8.3.20170426/bin/ghc-pkg" --force > --global-package-db > "/usr/local/ghc/ghc-HEAD/lib/ghc-8.3.20170426/package.conf.d" update > rts/dist/package.conf.install > Reading package info from "rts/dist/package.conf.install" ... done. > : Warning: Unrecognized field exposed-modules on line 708 > : Warning: Unrecognized field key on line 703 > : Warning: Unrecognized field id on line 702 > : Warning: Unrecognized field version on line 701 > : Warning: Unrecognized field name on line 700 > : invalid package identifier: > : missing id field > make[1]: *** [install_packages] Error 1 > make: *** [install] Error 2 I *think* that may be an issue with using an older version of cabal. It should be 1.24.*. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: testsuite not in GHC 8.2.1-rc1 source tarball ?
Ben Gamari wrote: > Well, unfortunately one of the changes that just barely missesd the > window for -rc1 was a fix to a rather serious memory leak in the compiler > (#13426). Thats going to fixed for rc2? Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Compiling CMM tests with LLVM
Erik de Castro Lopo wrote:
> Hi all,
>
> I'm working on a minor change to CMM (#13442) and while writing the
> tests realized that the CMM tests were only run with `-fasm` and not
> with `-fllvm`. Furthermore other than running the test manually myself,
> I could not figure out how to make it compile with LLVM.
>
> My test (in my WIP local branch) is:
>
> testsuite/tests/codeGen/should_compile/T13442.cmm
>
> and I updated the `all.T` in that same directory with the line:
>
> test('T13442', [cmm_src], compile, ['-dcmm-lint'])
>
> Anyone have any clues as to how to make this compile with LLVM if
> LLVM is available? I suspect it should probably be turned on for
> the vast majority of the CMM tests.
Ok, I added the following function to `testlib.py`:
def cmm_src_llvm( name, opts ):
opts.only_ways = ['optllvm', 'llvm', 'debugllvm']
opts.cmm_src = 1;
and changed my test set up to:
test('T13442', [cmm_src, cmm_src_llvm], compile, ['-dcmm-lint'])
Would still be interested to know if this is the correct way and
if there is a better way.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Compiling CMM tests with LLVM
Hi all,
I'm working on a minor change to CMM (#13442) and while writing the
tests realized that the CMM tests were only run with `-fasm` and not
with `-fllvm`. Furthermore other than running the test manually myself,
I could not figure out how to make it compile with LLVM.
My test (in my WIP local branch) is:
testsuite/tests/codeGen/should_compile/T13442.cmm
and I updated the `all.T` in that same directory with the line:
test('T13442', [cmm_src], compile, ['-dcmm-lint'])
Anyone have any clues as to how to make this compile with LLVM if
LLVM is available? I suspect it should probably be turned on for
the vast majority of the CMM tests.
Erik
--
----------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: can't validate on Linux
Richard Eisenberg wrote: > /home/rae/ghc/ghc-valid/bindisttest/install > > dir/lib/ghc-8.3.20170312/package.conf.d/package.cache.lock I'd try manually deleting that file. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Handling of unlifted types
Hi all, I'm working on pulling the core parts of Joachim Breitner's ghc-heap-view library into GHC. The WIP Phab review is here: https://phabricator.haskell.org/D3055 Currently that library has a function: getClosureData :: a -> IO Closure which works fine for lifted types. However, some of the supported closure types in http://hackage.haskell.org/trac/ghc/browser/includes/rts/storage/InfoTables.h actually refer to unlifted types, like the `MUT_ARR_PTRS_*` and `SMALL_MUT_ARR_PTRS_*`. I've had a look at the levity polymorphism stuff implemented in ghc 8.0 and came up with a new type for `getClosureData`: getClosureData :: forall (r :: RuntimeRep) (a :: TYPE r). a -> IO Closure but that results in: A representation-polymorphic type is not allowed here: Type: a Kind: TYPE r In the type of binder ‘x’ Am I barking up the wrong tree here? Any one have a clue on how I might make progress on this? Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Github repos for boot libraries
Hi all, Currently if I go to the Github mirror for a boot library like transformers: https://github.com/ghc/packages-transformers I see the text: Mirror of packages-transformers repository. DO NOT SUBMIT PULL REQUESTS HERE This may well be true, but it is far less that useful, because although it tells me I can't submit I pull request, It doesn't tell me what I should do to get my issue addressed. Would it be possible to get these messages updated for all of these mirrored repos? Thanks, Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Competing with C in a simple loop
Christopher Done wrote: > But if you scroll down the README to the 182kb file example, you see that > hexml takes 33us and xeno takes 111us. That's surprising to me because I'm > doing just a walk across a string and hexml is doing a full parse. It's > written in C, but still, 3x faster AND doing allocations and more work. > > I tried replacing the ByteString with a raw Ptr Word8 and it didn't make a > difference, actually increased time a little bit. The code you have written still looks like Haskell code. When I write Haskell code that needs to compete speedwise with C, it usually ends up looking like C as well. My suggestion is to drop `Data.ByteString.elemIndex` in favour of direct unsafe array accesses. If I find a bit of time over the next couple of days I might have a crack at this. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Confused about the sub-modules
Edward Z. Yang wrote: > Not any more. The commit just has to exist in the remote repo (that's > what the lint checks.) So this is where I am running into trouble. Everything for process and directory is fine, but for Cabal and containers, the git repo on git.haskell.org is missing the commits I need. (No need to CC me, I'm subscribed to ghc-devs). Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Confused about the sub-modules
Hi all, I'm a bit confused about how the GHC dev tree handles submodules like libraries/Cabal, libraries/process, libraries/directory and libraries/containers. All of these libraries/submodules seem to have their own github projects where people can submit PRs, but once the commits have been made there, what is the process to get submodules updated in the GHC tree? Any light people can shed on this process would be appreciated. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Heads up: Git HEAD now requres LLVM 3.9
Hi all, With the landing of https://phabricator.haskell.org/D2719 GHC git HEAD now requires LLVM 3.9. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Linux -> Windows cross-compiling failed
Bernard de la Paz wrote: > I try to cross-compile GHC 8.0.1 with x86_64-mingw toolchain (gcc 6.2.1) and > native GHC 8.0.1. Sources are from > http://downloads.haskell.org/~ghc/8.0.1/ghc-8.0.1-src.tar.xz > cp mk/build.mk.example mk/build.mk > sed -i '1iBuildFlavour = perf' mk/build.mk I'm pretty sure you will have better results with build flavour 'quick-cross' or 'perf-cross'. > sed -i '1iStage1Only = YES' mk/build.mk > sed -i '1iHADDOCK_DOCS = NO' mk/build.mk > ./configure --prefix=~/x86_64-mingw \ > --target=x86_64-unknown-mingw32 \ > --with-gcc=/usr/bin/x86_64-w64-mingw32-gcc \ > --with-ld=/usr/bin/x86_64-w64-mingw32-ld \ > --with-nm=/usr/bin/x86_64-w64-mingw32-nm \ > --with-ar=/usr/bin/x86_64-w64-mingw32-ar \ > --with-ranlib=/usr/bin/x86_64-w64-mingw32-ranlib It should be sufficient to just do: ./configure --target=x86_64-w64-mingw32 Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows build broken -- again
Simon Peyton Jones via ghc-devs wrote: > In file included from rts\CheckUnload.c:16:0: error: > > > > rts\LinkerInternals.h:284:15: error: > > error: unknown type name 'UChar' > > STATIC_INLINE UChar * There's a patch up on Phab that should fix that: https://phabricator.haskell.org/D2700 Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Submitting a patch for hsc2hs
Erik de Castro Lopo wrote: > How long ago was it that it worked, because it doesn't now. With a little help from mpickering I got this up on Phab: https://phabricator.haskell.org/D2677 Thanks Matt! Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Submitting a patch for hsc2hs
Ryan Scott wrote: > Hi Erik, > > I'm not sure if the hsc2hs repo [1] has "official" Phabricator > integration, but what I did when I submitted a patch to hsc2hs was: > > 1. Commit your changes > 2. Because the hsc2hs repo doesn't have an .arcconfig file, you have > to manually point arcanist to the right URL by running: > > arc diff --conduit-uri=https://phabricator.haskell.org How long ago was it that it worked, because it doesn't now. I get: Exception ERR-CONDUIT-CORE: Validation errors: - Creation of this diff was rejected by Herald rule H51. Rule: Reject diffs with no repository set Reason: You must specify an existing repository to attach the diff to. (Run with `--trace` for a full exception trace.) Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Submitting a patch for hsc2hs
HI all,
How would I go about submitting a patch to hsc2hs? Patch below.
Erik
From 446e43994e39c763e2fcc3a3accea3e61c3ce767 Mon Sep 17 00:00:00 2001
From: Erik de Castro Lopo
Date: Fri, 4 Nov 2016 20:08:06 +1100
Subject: [PATCH] Fix type signature of main test function
During C compiler feature testing, the `main` function was defined
with a parameter list of `(int argc, char *argv [])` but these
parameters were not used. This results in compiler warnings when
the generated file is compiled with the `-Wextra` warning flag
added to the `cc-options` of the cabal file.
---
DirectCodegen.hs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/DirectCodegen.hs b/DirectCodegen.hs
index 37564ee..2a88784 100644
--- a/DirectCodegen.hs
+++ b/DirectCodegen.hs
@@ -63,7 +63,7 @@ outputDirect config outName outDir outBase name toks = do
outTemplateHeaderCProg (cTemplate config)++
concatMap outFlagHeaderCProg flags++
concatMap outHeaderCProg specials++
-"\nint main (int argc, char *argv [])\n{\n"++
+"\nint main (void)\n{\n"++
outHeaderHs flags (if needsH then Just outHName else Nothing)
specials++
outHsLine (SourcePos name 0)++
concatMap outTokenHs toks++
--
2.10.1
--
----------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building with recent binutils require --no-pie
Erik de Castro Lopo wrote: > Unfortunately, that is not sufficient. With the three patchs you listed > and the configure options above, the resulting GHC still fails to build > the 'magic' due to something going wrong with hsc2hs: Just to be clear, this is patching the 8.0.1 release. It seems that the final piece of the puzzle is the cabal 1.24.1.0 release which is due RealSoonNow! https://github.com/haskell/cabal/issues/4080 Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building with recent binutils require --no-pie
Alan & Kim Zimmerman wrote: > For anyone building on Debian testing or similar and getting linker > failures, there is currently a workaround in progress by Ben Gamari that > can be used. > > It is based on first applying D2672, D2673, and D2674 and then configuring > with > > ./configure \ > CONF_CC_OPTS_STAGE2=-fno-PIE \ > CONF_GCC_LINKER_OPTS_STAGE2=-no-pie \ > CONF_LD_LINKER_OPTS_STAGE2=-no-pie \ > CONF_CC_OPTS_STAGE0=-no-pie \ > CONF_GCC_LINKER_OPTS_STAGE0=-no-pie \ > CONF_LD_LINKER_OPTS_STAGE0=-no-pie \ > CONF_HC_OPTS_STAGE0=-optl=-no-pie Unfortunately, that is not sufficient. With the three patchs you listed and the configure options above, the resulting GHC still fails to build the 'magic' due to something going wrong with hsc2hs: Configuring magic-1.1... Building magic-1.1... Preprocessing library magic-1.1... /usr/bin/ld: dist/build/Magic/Data_hsc_make.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status linking dist/build/Magic/Data_hsc_make.o failed (exit code 1) command was: /usr/bin/gcc dist/build/Magic/Data_hsc_make.o dist/build/Magic/Data_hsc_utils.o -o dist/build/Magic/Data_hsc_make -fno-PIE -fno-stack-protector -lmagic -L/usr/lib/ghc-8.0/lib/base-4.9.0.0 -Wl,-R,/usr/lib/ghc-8.0/lib/base-4.9.0.0 -L/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1 -Wl,-R,/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1 -lgmp -L/usr/lib/ghc-8.0/lib/ghc-prim-0.5.0.0 -Wl,-R,/usr/lib/ghc-8.0/lib/ghc-prim-0.5.0.0 -L/usr/lib/ghc-8.0/lib/rts -Wl,-R,/usr/lib/ghc-8.0/lib/rts -lm -lrt -ldl -lffi Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: A collection of type-inference refactorings. (3f5673f)
Simon Peyton Jones via ghc-devs wrote:
> You'll have seen a brief flurry of commits from me, of which this is the
> biggest. I've managed to spend some time on the typechecker recently, and
> this is the result.
>
> I'm pleased with the results (simpler code, more predictable behaviour),
> but although I worked through the changes with Richard, I may have
> introduced new bugs, so keep an eye out.
Simon,
I suspect these commits may be responsible for 11 test failures:
Unexpected results from:
TEST="T9857 T12007 T9732 T9783 T9867 unboxed-wrapper-naked match-unboxed num
T12698 T4439 unboxed-wrapper"
SUMMARY for test run started at Sun Oct 23 16:56:26 2016 AEDT
0:00:02 spent to go through
11 total tests, which gave rise to
47 test cases, of which
36 were skipped
0 had missing libraries
0 expected passes
0 expected failures
0 caused framework failures
0 unexpected passes
11 unexpected failures
0 unexpected stat failures
Unexpected failures:
deSugar/should_compile/T4439.run T4439 [exit code non-0]
(normal)
ghci/scripts/T12007.run T12007 [bad stderr] (ghci)
patsyn/should_compile/num.run num [exit code non-0] (normal)
patsyn/should_compile/T9732.run T9732 [exit code non-0]
(normal)
patsyn/should_compile/T9857.run T9857 [exit code non-0]
(normal)
patsyn/should_compile/T9867.run T9867 [exit code non-0]
(normal)
patsyn/should_compile/T12698.run T12698 [exit code non-0]
(normal)
patsyn/should_fail/unboxed-wrapper-naked.run unboxed-wrapper-naked [stderr
mismatch] (normal)
patsyn/should_run/T9783.run T9783 [exit code non-0]
(normal)
patsyn/should_run/match-unboxed.run match-unboxed [exit code
non-0] (normal)
patsyn/should_run/unboxed-wrapper.run unboxed-wrapper [exit code
non-0] (normal)
They all fail with exactly the same callstack:
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.1.20161022 for x86_64-unknown-linux):
ASSERT failed!
Infer{apr,2 True} :: TYPE t_apq[tau:2]
a_a1pr[tau:2]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58
in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in
ghc:Outputable
assertPprPanic, called at compiler/typecheck/TcUnify.hs:547:56 in
ghc:TcUnify
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58
in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in
ghc:Outputable
pprPanic, called at compiler/utils/Outputable.hs:1123:5 in
ghc:Outputable
assertPprPanic, called at compiler/typecheck/TcUnify.hs:547:56 in
ghc:TcUnify
Cheers,
Erik
--
----------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Aargh! Windows build is broken AGAIN
Simon Peyton Jones via ghc-devs wrote: > I really wish I did not have to be the Windows integration server. > Currently, from a clean build of HEAD, I'm getting > > libraries\base\GHC\Event\TimerManager.hs:62:3: error: > > error: #error not implemented for this operating system > > # error not implemented for this operating system > >^ > I'd revert something if I could, but I can't see what to revert. Help, > please! According to git annotate, that error line was added in 2012 so that commit is unlikely to be cause. I'll log into my Windows VM and see if I can figure it out. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
SafeHaskell vs TemplateHaskell
Hi all, I tried to fix trac ticket #12511 (template-haskell's Language.Haskell.Syntax module should be Trustworthy) but in doing so I began to think this is actually a bad idea. Specifically, I suspect its actually possible to craft something using TH that bypasses the guarantees that Safe is supposed to ensure. Comments? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Status of Harbormaster
Ben Gamari wrote: > It's a bit unclear how far we should extend test coverage. In the future > I think I will at very least add an i386 Ubuntu environment, but we > could go farther still. For instance these platforms immediately come to > mind, > > * x86_64 FreeBSD > * x86_64 Solaris > * ARM Linux (although this could be quite tricky given the speed of >these machines) > * AArch64 Linux That would be awesome if we could get access to a decent (by which I mean server grade, with at least 4 cores and 8 Gig of RAM). The other option for ARM/Linux and AArch64/Linux is cross-compile builds. Just building GHC as a cross-compiler for these targets would shave out a lot of bugs. Let me know if you're interested. Its really pretty easy to set up on a Debian or Ubuntu system. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SSH failing on Windows
Simon Peyton Jones via ghc-devs wrote: > > But 'git push' says > > /c/code/HEAD$ git push > > Permission denied (publickey). > > fatal: Could not read from remote repository. And then I read the error message. That message suggests that the SSH key is not known by the remote repository. Did you copy your SSH keys from your old machine to your new machine? Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SSH failing on Windows
Simon Peyton Jones via ghc-devs wrote: > Now my problem is that 'git push' doesn't work. My 'pushurl' is > pushurl = ssh://g...@git.haskell.org/ghc.git > which is correct I think. Try pushurl = g...@git.haskell.org/ghc.git I think the "ssh://" was for older versions of git. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
GHC build currently broken on OS X and Windows
Hi all. The recent Compact Regions commit (cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453) builds fine on Linux but doesn't build on OS X and is at least 99% certain not to build on Windows. I'm in the process of fixing it, but it will be 24-36 hours before I have a patch ready. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Heads up LLVM 3.8
HI all, This is just a heads up that git HEAD will soon be switch to LLVM 3.8. The Phab patch is here: https://phabricator.haskell.org/D2382 I suspect the ghc-8.0 branch will continue to use LLVM 3.7 for all the 8.0 releases. I also suspect that LLVM 3.9 will be released (and that we will switch to it) before the first RC release of 8.2. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Linker.c broken
Phyx wrote: > I can build and validate in about an hour myself using 9 jobs on a core i7. > If I revert the change in the testsuite preventing parallel runs for > Windows Oh dear, why is that? Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Linker.c broken
Ben Gamari wrote: > Indeed; and I think it would also be worthwhile also setting up at least > a nightly build validating 32-bit Linux. If its not integrated with the CI, I'm not sure how useful that is. As you may remember I have a Jenkins instance. Once a day it polls git and if there are new commits sicen the last time it was polled, it builds the following: Arch OS BuildFlavour x86_64 linuxperf x86_64 darwin perf x86_64 linuxperf-llvm x86_64 linuxdevel2/unregisterised x86_64 linuxdevel2 with Clang x86_64 Linuxperf powerpc linuxdevel2 powerpc linuxdevel2/unregisterised armhflinuxdevel2 armhflinuxdevel2/unregisterised as well as cross-compiling from x86_64/linux to armhf/linux and arm64/linux. This does catche the ocassional problem but when something shows up but fixing them is a bigger problem. FOr example, I simply have not had time to look at : https://ghc.haskell.org/trac/ghc/ticket/12238 Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Linker.c broken
Simon Marlow wrote: > It was actually intentional. The patch validated on Travis: > https://travis-ci.org/simonmar/ghc/builds/141572355 and I didn't think it > was worth having it reviewed (but if you want to review all linker patches > I'd be happy to put them on Phabricator in the future). I *try* (time permitting) to review all linker patches. I've just started a new job (coding Haskell) but it means I've got a bit less time to hack on GHC. I have a Phab rule to notify me on all patches that touch Linker.c. I try to look at all of them, but sometimes they have been accepted by others and committed before I even look at them. For the ones that are nor accepted and committed before I get to them, I often test them on PowerPC or Arm and I'm also willing to keep on doing this (time permitting). Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Linker.c broken
Simon Marlow wrote: > I will fix it, sorry about this. Unfortunately I can't really add a > Windows validate into my workflow because it would mean rebooting my laptop > into Windows and not doing anything else for several hours. Even building as 32 bit would have shaken out a bug in the format specifiers to the debugBelch statement. Are you on Linux? I use a 32 bit debian chroot on my otherwise 64 bit Debian system. > We need some CI support for Windows - Ben/Austin any thoughts on this? That would be an improvement, but it doesn't help for other OSes like Aix and Solaris or other CPUs. I also noticed that patch bypassed Phabricator. I assume that was a mistake. I've done it myself. We need to be particularly careful with the RTS code because its so fragile. It needs to be build and tested on a wide variety of systems. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Linker.c broken
Simon Peyton Jones via ghc-devs wrote:
> rts\Linker.c:1480:28: error:
>
> error: format '%ls' expects argument of type 'wchar_t *', but argument 3
> has type 'void *' [-Werror=format=]
>
> debugBelch("%p is in %" PATH_FMT, addr,
I get an error on code from this commit on arm/linux.
Erik
--
----------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: T8761 failing for ext-interp
Simon Marlow wrote: > Is it just perf-llvm? It seems to be. I build quite a large number of configurations in my Jenkins instance. All of the configurations other than perf-llvm built fine. > Does validate fail? I actually haven't tried validate directly because my build configrations explicitly set BuildFlavour before building and running 'make test'. > What platform is this? This particular failure is on x86_64/linux. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: T8761 failing for ext-interp
Erik de Castro Lopo wrote:
> > Erik, could it be the same symptom as Edward is seeing here?
> > https://ghc.haskell.org/trac/ghc/ticket/12230
>
> Yes it is.
Just to provide a little more info, the tests I'm seeing fail (perf-llvm)
are:
TEST="TH_repUnboxedTuples T10828 T10596 TH_reifyMkName T9064 T8628
T11797 T10796b TH_reifyDecl2 TH_repPrim2 T10891 ClosedFam1TH
ghci006 TH_reifyInstances TH_repPrim T9692 prog001 TH_Roles3
T10796a T8639_api TH_reifyDecl1 T5362 T T5037 T8884 TH_TyInstWhere2
T11341 TH_foreignCallingConventions T3920 T7477 T9738 process009 T8953
T4135 T2700 TH_Roles4 T9262 TH_RichKinds2 TH_repGuard T8761 ghci004
T4188
TH_RichKinds"
Some examples of the failue are:
T10596.hs:1:1: error:
Exception when trying to run compile-time code:
ghc-stage2: ghc-iserv terminated (-11)
Code: do { putQ (100 :: Int);
x <- (getQ :: Q (Maybe Int));
($) runIO print x;
}
T9064.hs:1:1: error:
Exception when trying to run compile-time code:
ghc-stage2: ghc-iserv terminated (-11)
Code: do { info <- reify ''C;
($)
runIO
do { ($) putStrLn pprint info;
};
return [] }
TH_RichKinds2.hs:1:1: error:
Exception when trying to run compile-time code:
ghc-stage2: ghc-iserv terminated (-11)
Code: let
fixKs :: String -> String
fixKs s = ...
in
do { decls <- [d| data SMaybe :: (k -> *) -> (Maybe k) -> *
where
SNothing :: SMaybe s Nothing
SJust :: s a -> SMaybe s (Just a)
type instance Map f (h : t) = (f h) : (Map f t)
type instance Map f '[] = '[] |];
reportWarning (fixKs (pprint decls));
}
So yes, very similar to #12230.
Erik
--
------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: T8761 failing for ext-interp
Simon Marlow wrote: > Erik, could it be the same symptom as Edward is seeing here? > https://ghc.haskell.org/trac/ghc/ticket/12230 Yes it is. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: T8761 failing for ext-interp
Richard Eisenberg wrote: > Phab tells us that T8761 is failing for the ext-interp way, as of > d2006d050e7a9111c0c448d6262f8994ef5761b7 (Run all TH tests with > -fexternal-interpreter (#12219)). See https://phabricator.haskell.org/B10229 Compling with BuildFlavour == perf-llvm results in 42 test failures, the vast majority being TH related along with a small number of GHCi tests. I'm currently doing a git bisect to find which commit broken this, but I do know its something after 9a34bf1985. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Phabricator not sending emails
Edward Z. Yang wrote: > As far as I can tell, Phabricator is not sending emails. > I noticed when some of my diffs updated but I didn't get > any emails, and doublechecked by asking for a password > reset email. I'm getting Phab emails for my reviews. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC 8.0.1-rc3 source tarball availability
George Colpitts wrote: > My understanding is that the required version of llvm is 3.7. Is it safe to > assume that 3.7.1 is also okay? > > On Sun, Apr 10, 2016 at 12:05 PM Ben Gamari wrote: > > > tl;dr: If you would like to produce a binary distribution for GHC > >8.0.1-rc3 then let us know, grab the source distribution and > >start building. The binary distributions will be all released one > >week from today. > > > > > > Hello GHC packagers, > > > > Austin and I are happy to announce the release of the 8.0.1-rc3 source > > distribution to binary packagers. You will find the tarball and usual > > assortment of signatures at > > > > http://downloads.haskell.org/~ghc/8.0.1-rc3/ > > > > This release is the first where we are following our new release policy > > [1], where a one-week delay will be introduced between the release of > > the source and binary distributions. The goal of this policy is to give > > all platforms the opportunity for support from the first day of a > > release. > > > > If all of the expected binary releases are submitted before the > > week-long delay is through, we can move forward with the release ahead > > of schedule. Given how late release candidate 3 is, we'd naturally like > > to get the binary releases out as soon is possible: The sooner we can > > get this -rc out the door the sooner we can get to the final release. > > Moreover, it would be appreciated if you could confirm that you intend > > to offer a binary distribution this release. > > > > Otherwise, let either Austin or I know if you have any trouble building > > your distribution. I have yet to push the 8.0.1-rc3 tag in case we > > encounter unexpected issues but all of my builds with this tarball > > thusfar have gone quite well. > > > > Good luck and thanks for all of your work! > > > > Cheers, > > > > - Ben > > > > > > [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: TH changes for ghc 8.0
Christiaan Baaij wrote: > mapM conT :: [Name] -> Q [Type] :: [Name] -> Q [Pred] :: [Name] -> CxtQ > > Those `Name`s are Class names, which are Type constructors, hence `conT` Thanks Christiaan, thats got it for me. I'll update the migration guide as well. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: TH changes for ghc 8.0
Erik Hesselink wrote: > That function does exist for me in rc2: > > cxt :: [PredQ] -> CxtQ Ah, there is it is! But I'm trying to write code that works with ghc-7.10 *and* ghc-8.0 (yes, I'm using CPP in all its ugly glory), but if I've got code that works with ghc-7.10 (the first type signature below): > - dataD :: CxtQ -> Name -> [TyVarBndr] -> [ConQ] -> [Name] -> > DecQ > + dataD :: CxtQ -> Name -> [TyVarBndr] -> Maybe Kind -> [ConQ] -> CxtQ -> > DecQ how do I convert it to the second? Adding a `Nothing` for the `Maybe Kind` argument is easy, but if the old code has `[Name]`, how do I convert it to a `CxtQ`. The `cxt` function won't do it. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
TH changes for ghc 8.0
Hi all, I'm working on updating persistent-template for ghc-8.0 and reading the migration guide: https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0#template-haskell-2.11.0.0 specifically the bit that says: > * the DataD, NewtypeD, DataInstD, and NewtypeInstD constructors have a new > field `Maybe Kind` (#10828), and take a `CxtQ` instead of a `[Name]` for > the derived classes (#10819). If you don't know what to do, use `Nothing` > for the kind signature, and `cxt []` for the derived classes. Using `Nothing` as suggested is working out well enough, but I'm a bit befuddled by the change from `[Name]` to `CtxQ` and the usage of `ctx []`. I can't seem to find *any* function named `ctx`. Any light people may be about to shed on this would be much appreciated. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: 7.10.3 fails to build with Xcode 7.3
Manuel M T Chakravarty wrote: > I just noticed that GHC 7.10.3 (latest release version) fails to build > with version 7.3 of Xcode (which just came out of beta). Maybe this is due to > > https://ghc.haskell.org/trac/ghc/ticket/11744 Yes, pretty sure that is the problem. I believe Carter (and maybe Luite) are working on it. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Loading GHC into GHCi (reprise)
Erik de Castro Lopo wrote: > I even tied adding `-icompiler/llvmGen` to the above command line (from > hell) before I noticed that it was already present. Well I have a solution, I modified the module export list as follows: -module LlvmCodeGen ( llvmCodeGen, llvmFixupAsm ) where +module LlvmCodeGen ( llvmFixupAsm, module LlvmCodeGen ) where which gives me access to all top level functions in that module. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: necessary to build for all platforms?
Richard Eisenberg wrote: > Watching the files being compiled slowly scrolling by, as I too often do, > led me to this question: Is there a reason that my machine (an x86-based Mac) > is building modules in the SPARC or PPC directory? They do need to be built at some point. > These absolutely need > to be compiled when validating on any machine, If they aren't build during devel2 but are build during validation then that would be sufficient. > If I am, is it reasonable to try to teach the build scripts how to avoid doing > this? As someone who cares about PowerPC and some other arches, I agree that this is a reasonable request on the face of it. I am a little concerned about the difficulty of teaching the build system to do it and I'm not sure how big the payoff is. These arch specific files are probably less than 1% of the total file count. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Loading GHC into GHCi (reprise)
Hi all, Recently Richard showed us how to load GHC into CHCi which ended up being documented here: https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler That very useful for some things, but doesn't give you access to symbols and types that have not been exported. Specifically, I'm interested in some of the inner workings of the file `compiler/llvmGen/LlvmCodeGen.hs` and I've even managed to load it into GHCi using the command line: inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci -fobject-code \ -DSTAGE=1 -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen \ -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn \ -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen \ -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename \ -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn \ -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils \ -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen \ -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. \ -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -XHaskell2010 \ compiler/llvmGen/LlvmCodeGen.hs and it loads all the modules require, but then seems to mess up the symbol table so that it can't even find top level functions in the module it has just loaded. Prelude LlvmCodeGen> :t LlvmCodeGen.cmmDataLlvmGens :1:1: error: Not in scope: ‘LlvmCodeGen.cmmDataLlvmGens’ No module named ‘LlvmCodeGen’ is imported. I even tied adding `-icompiler/llvmGen` to the above command line (from hell) before I noticed that it was already present. Anyone have any idea why this doesn't work? Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Error: selected processor does not support ARM mode `ldrd r0, r1, [r7, #64]'
Ben Gamari wrote: > There are several places where Thumb instructions could come from, > > 1. GHCi produced them in mkJumpToAddr > > 2. native code compiled with GCC, which defaults to Thumb on many > systems > > 3. system libraries, which are Thumb on many distributions > > The solution which Erik implemented was to switch entirely to ARM. (1) > was addressed by changing the GHC, (2) was fixed by explicitly passing > -marm to GCC. I'm actually not sure the state of (3). Unfortunately, (3) is likely to still be broken. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]'
Joachim Breitner wrote: > Erik, can you comment on that? Well, I agree that not being able to build GHC on `armel` is a regression with respect to 7.10.2, but in my opinion, GHC 7.10.2 was not actually usable on Arm, at least not on `armhf` (not sure about `armel` as I don't have an `armel` setup). Currently, GHC treats all 32 bit Arm systems as the same. I think this shows that we need at least the equivalent of Debian's `armhf` (which is what we currently have) and Debian's `armel`. I'm not even too sure what `armel` actually is. Is it Armv4 with softfloat? Is so, I can probably create a chroot on one of my fast `armhf` boards. The main problem is that Arm needs more developer man power. For the last several months my employer has allowed me to allocate some of my work hours to improve GHC on Arm and Arm64. That however is about to come to an end and at the moment I seem to be the only person working on Arm. That work is also made more difficult by the fact that changes in the master branch seem to break Arm (and/or PowerPC) every 2-3 weeks. Sometimes just fixing new breakage in master takes up all the time I have. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Differential] [Closed] D975: ELF/x86_64: map object file sections separately into the low 2GB
Thomas Miedema wrote: > This commit is causing segmentation faults on Travis (DYNAMIC_GHC_PROGRAMS > = NO): > https://s3.amazonaws.com/archive.travis-ci.org/jobs/85552765/log.txt This is now trac ticket #10994. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC and LLVM
Manuel M T Chakravarty wrote: > That sounds great. Can your Jenkins instance maybe also push > the reports to one of the GHC lists, so everybody can see what > the state of play is? Well currently the report log is 7Meg and I'm sure everyone would appreciate it if I kept those to myself. Currently the state of play can be seen from the patches listed here: https://github.com/erikd/ghc-llvm-next/tree/master/patches These are the patches that currently need to be applied to GHC git HEAD to build it against LLVM git head. The first, 00-configure-3.8.patch switches GHC from using LLVM 3.7 to using 3.8. The second, 01-bitcast.patch is needed because the syntax of the bitcast operation has changed in some situations. The number of tests failing with this setup is the same as the number failing with GHC git head compiled against the 3.7 (and 3.6) release of LLVM. Cheers, Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
GHC and LLVM
Hi all, As some of you may have noticed the LLVM requirements for GHC HEAD has just switched from version 3.6 to 3.7. This was mainly to support Arm64 (aka AArch64 aka Armv8-a), for which llvm-3.6 was badly broken. Since figuring out what needed to change from 3.6 to 3.7 was rather painful, I decided to set up a small project to help us GHC devs keep up with what happens in the LLVM dev world. http://github.com/erikd/ghc-llvm-next/ The project is a build script (actually a Makefile) and a set of patches) which does the followiing: * clones/updates LLVM from git, builds it and installs it locally * clones/updates GHC from git * applies patches git GHC so that GHC builds against the locally build LLVM tools. * builds GHC and then runs the testsuite I plan on running the above build on a daily basis in my own personal Jenkins instance in order to track changes in GHC and LLVM. Others are free to do the same and I'm happy to take pull requests. This project may also be interesting or useful for people testing out up-coming LLVM features with GHC. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC 7.10 complie time regression
Simon Peyton Jones wrote: > 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. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Two step allocator for 64-bit systems
Dear Giovanni, Your commit: commit 0d1a8d09f452977aadef7897aa12a8d41c7a4af0 Author: Giovanni Campagna Date: Fri Jul 17 11:55:49 2015 +0100 Two step allocator for 64-bit systems fails for me on Arm64 (also known as AArch64) Linux. I was wondering if you might be able to look at this ticket I've raised and hopefully shed some light on this issue: https://ghc.haskell.org/trac/ghc/ticket/10682 Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: armv7 "invalid instruction" problem building cabal
Ben Burdette wrote: > I've been trying to get going with ghc 7.10.2 on armv7 debian, problem > is described here: > > http://stackoverflow.com/questions/32124334/ghc-armv7-binary-cabal-illegal-instruction I suspect your problem may be related to this one: https://ghc.haskell.org/trac/ghc/ticket/10375 which I started work on, got stuck and haven't had time to return to. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: armv7 "invalid instruction" problem building cabal
Ben Burdette wrote:
> No prob! Either forum is ok for me. get info output:
Ok, this:
> ,("ld command","/usr/bin/ld.gold")
means GHC uses ld.gold explicitly
and this
> ,("LLVM llc command","/usr/bin/llc-3.5")
> ,("LLVM opt command","/usr/bin/opt-3.5")
means its using the right versions of the llvm tool.
Try compiling and running a simple "Hello world" type program.
Try compiling with and without optimisation.
Erik
--
------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: armv7 "invalid instruction" problem building cabal
Ben Burdette wrote: > I've been trying to get going with ghc 7.10.2 on armv7 debian, problem > is described here: > > http://stackoverflow.com/questions/32124334/ghc-armv7-binary-cabal-illegal-instruction Sorry, I'll answer here instead of SO if thats OK. Mostly because I don't have an answer and need to ask you to provide more info. As a first step, what is the output of "ghc --info"? Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Forcing a linking error?
Dear ghc-devs, There is a commonly used library which has at least one function that when compiled into a program, requires the threaded run time system. Without the threaded runtime, the program just hangs. One kludgy solution to this problem is to have the function check for Control.Concurrent.rtsSupportsBoundThreads being true and throwing an error if its not. However, it would be much nicer if this could be turned into a link time error. Anyone have any ideas how this might be done? Cheers, Eri -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: the platform has outgrown Travis-CI
Mark Lentczner wrote: > I finally figured out what was wrong with the Travis CI build for Haskell > Platform, and got it all working w/hvr's .debs of GHC (for the boot > compiler)... and ran smack into this: Another option you or others may want to pursue is setting up a self manager Jenkins instance. I have a personal Jenkins instance that includes Arm and PowerPC slave build nodes. Setup is and maintenance is relatively easy, but slightly less convienient than Travis. Cheers, Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HEADS UP: Final call for 7.10.2 is soon
Austin Seipp wrote: > - If your bug is critical, please explain why! We really want to > kill showstoppers ASAP, because bugs are much cheaper to fix early. If > that's the case we can bump the priority if it's necessary to make > things clear. I know Arm is not a tier 1 platform, but I think #10375 is rather important. The problem is that in ghci the following two statements: data X = Y deriving Eq Y == Y will cause ghci to segfault. I've done some work debugging this, but it has proved rather elusive. This is a major regression with respect to ghc 7.8. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Debugging the RTS
Jost Berthold wrote:
> To build a GHC with debug-way RTS, you need to add GhcRtsWays += debug
> to your build.mk (also see mk/config.mk{.in}, which gathers the default
> ways to build depending on platform and build configuration).
Since we're talking about updating the documentation, I would like to
note that the identifuer "GhcRtsWays" is not present at all, anywhere
in the GHC tree :-).
I do however notice that the debug way is built by default.
I was also able to build a ghc-stage2 with the debug RTS by adding
"-debug" to GhcStage2HcOpts in mk/build.mk.
Cheers,
Erik
--
----------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: api annotations test failures
Joachim Breitner wrote: > Hi, > > I observe this on travis: > > Wrong exit code (expected 0 , actual 2 ) > Stdout: > > Stderr: > collect2: ld terminated with signal 9 [Killed] > make[3]: *** [t10358] Error 1 I've seen this just recently on these tests. Looking at /var/log/messages showed the `ld` process had been killed by the OOM killer. My instance of this was on armhf/linux with only 2Gig of RAM and no swap. I have to recompile the kernel to get swap :-(. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Debugging the RTS
Hi all, I'm trying to debug a AArch64/Linux specific RTS issue and digging around in the rts C code, I see a large amount of code wrapped in "#if DEBUG" type statements, but no way to enable in either mk/build.mk or it seems in any of the other build related settings files in the mk/ directory. The only way I have found to enable this debug code that actually works is to enable this DEBUG code is to edit mk/ghc.mk as follows: -STANDARD_OPTS += -DCOMPILING_RTS +STANDARD_OPTS += -DCOMPILING_RTS -DDEBUG However, once I do that I get a bunch of C synatx errors. I am doing this wrong or has the DEBUG code bit rotted? Cheers, Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HCAR DUE SOON: Please help edit!
Austin Seipp wrote: > After sitting on it for a bit, it dawned on me today that the may HCAR > report is due soon - in about two weeks! Is the recent work on Arm and Arm64 worth mentioning? For Arm, I'm hoping that 7.10.2 will work out of the box for arm/linux but fixes for #10368, #10375 and #10376 are still outstanding. For Arm64, I'm hoping 7.12.1 will work as well for arm64/linux as it does for 32 bit arm/linux. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RFC: "Native -XCPP" Proposal
Howard B. Golden wrote: > At the risk of antagonizing some (most? all?) of you, how about... > > -XCPP stands for the native CPP > -XGNUCPP stands for GNU's GCC CPP > -XClangCPP stands for Clang's CPP > -XCPPHS stands for CPPHS Oh please no! If someone releases a package on Hackage that uses -XGNUCPP, that will likely break on OSX because on OSX, gcc is actually clang. > ... with the hope that TH is the future? I suspect there will always be things that CPP does better than TH. What we need is a better CPP. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ghc-7.10 branch regression
Reid Barton wrote: > Why do we need to revert anything, can't we just make a one-character fix > of 3.6 to 3.5 on the ghc-7.10 branch? Even with that one character change the LLVM detection is not complete or correct. Specifically, building the compiler will enforce the right llvm version, but the binary-dist configure script just uses "llc" and "opt". Furthermore, I am pretty sure that #10292 is causes by llvm-3.5 and that if we use llvm-3.6 buildng on Arm works. Unfortunately building and testing on Arm takes a long time and I am still in the process of verifying this. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ghc-7.10 branch regression
Erik de Castro Lopo wrote: > At this point we need to decide whether: > >a) Require llvm-3.6 for 7.10.2 and later. I've done some testing on the ghc-7.10 branch (with a couple of patches cherry picked from master) with llvm-3.6 on amd64-linux. WIth this, there are 17 unexpected failures during validate: deriving/should_fail T7959 [stderr mismatch] (normal) deriving/should_fail drvfail005 [stderr mismatch] (normal) deriving/should_fail drvfail009 [stderr mismatch] (normal) indexed-types/should_fail SimpleFail14 [stderr mismatch] (normal) simplCore/should_compile spec-inline [stderr mismatch] (optasm) typecheck/should_compile T10195 [exit code non-0] (normal) typecheck/should_fail T2994 [stderr mismatch] (normal) typecheck/should_fail T3540 [stderr mismatch] (normal) typecheck/should_fail T7778 [stderr mismatch] (normal) typecheck/should_fail tcfail036 [stderr mismatch] (normal) typecheck/should_fail tcfail057 [stderr mismatch] (normal) typecheck/should_fail tcfail063 [stderr mismatch] (normal) typecheck/should_fail tcfail134 [stderr mismatch] (normal) typecheck/should_fail tcfail146 [stderr mismatch] (normal) typecheck/should_fail tcfail147 [stderr mismatch] (normal) typecheck/should_fail tcfail151 [stderr mismatch] (normal) typecheck/should_fail tcfail209 [stderr mismatch] (normal) All bit one oft these all seem to be stderr mismatches rather than actual problems. My validate run on armhf is still running. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
ghc-7.10 branch regression
Hi all,
It seems that commit 42448e3757 from git HEAD has been pulled into the
ghc-7.10 branch as commit 07da52ce2d.
This is problematic because that patch puts in a *requirement* for llvm-3.6
(which is good for git HEAD) but the llvm backend code in the ghc-7.10 branch
does not compiler with llvm-3.6. Specifically, on armhf I get:
/usr/bin/opt-3.6: /tmp/ghc16494_0/ghc16494_2.ll:7:6: error: unexpected type
in metadata definition
!0 = metadata !{metadata !"top", i8* null}
Furthermore, validating the ghc-7.10 branch on amd64-linis results in 16
unexpected failures (i'm currenty in the process of validating this branch
with the problematic commit reverted).
At this point we need to decide whether:
a) Require llvm-3.6 for 7.10.2 and later.
or
b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use
llvm-3.5 for the 7.10 series.
For option a) we would need to do the following:
* Pull in 5d5abdca31 from git HEAD that upgrades the LLVM backend to support
llvm-3.6 only.
* Pull in 485dba86 from git HEAD that updates the configure stuff and is
really the second part of 42448e3757.
For option b) we would need to do the following:
* Revert 07da52ce2d from ghc-7.10
* Apply the patch mentioned here:
https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11
At this point, my personal preference would be a). For me, git HEAD using
llvm-3.6 has been working a lot better on armhf and arm64 than the ghc-7.10
branch. Ticket #10234 has been set to 'merge' status to refect this.
Cheers,
Erik
PS : I would have raised another ticket about this, but I think the problem
here was actually caused by too many tickets and too many commits being
involved.
Interesting tidbits in case anyone is interested:
* On armhf, building the ghc-7.10 branch fails because we a generating LLVM IR
code targeted for llvm-3.5 and trying to compile it with llcm-3.6.
* The ghc-7.10 validates (with 16 unexpected failures) in x86 variants because
validation uses the NCG to build the compiler and ignores the requirement for
llvm-3.6, and then bindisttest compiler just uses "llc" and "opt" (in git
HEAD this difference between the compiler configure script and the binary-dist
configure script is fixed in 485dba86 and it is fixed in ghc-7.10 by the patch
in https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11).
--
----------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
GHC ARM64 calling convention
Hi Luke, I found your llvm git tree which contains a patch [0] implementing the GHC calling convention for GHC. I also notice that: a) It has not been submitted upstream. b) It can be cherry picked and applied on top of current llvm HEAD. c) It can be applied to the llvm 3.5 tree and most importantly of all d) It actually works. With this patch applied to the llvm 3.5 tree, I was able to build an x86_64-linux to aarch64-linux cross-compiler which was able to build a simple "hello world" program that actually ran correctly. Are you in the process of trying to get this patch into LLVM? Do you need any help? Cheers, Erik [0] https://github.com/lukexi/llvm/commit/2d351c3d095e2fe42bc287947404d884841a1d01 -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Ben Gamari wrote: > 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 (again) due to a bug in the GHC calling convention > implementation; an LLVM fix is waiting to be merged > > * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6 > support will likely need to wait until 7.12 > > * Austin's LLVM packaging proposal seems very much like the right way > forward > > * Anticipating this proposal, I have started collecting [2] > optimization passes I've recently been working on amd64-linux to armhf-linux and aarch64-linux cross-compilers. In addition to the above: * LLVM 3.6 that Ben mentions above has not yet been released and is still a work in progress. A commit to the LLVM tree made as recently as December 17th means LLVM head no longer compiles LLVM IR code generated by GHC (metadata issue mentioned in #9920). * LLVM uses C/C++ asserts liberally and these asserts get compiled out during optimised builds (eg for Linux distributions). The removal of these asserts results in llvm binaries that *silently* generate incorrect binaries (see #9920 which is Ben's second bullet point above). For instance, I built an amd64-linux to aarch64-linux cross compiler which generated executables that crashed immediately. When I switched to a debug version of LLVM, LLVM's opt and llc suddenly started showing assertion failures all over. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC Weekly News - 2014/12/16
Austin Seipp wrote: > - This week, Austin managed to secure two sponsors for > GHC/Haskell.org. We've been given a wonderful set of ARM buildbots > (running in the cloud!) and a new, incredibly powerful POWER8 machine > to use (with over 170 hardware threads available, for scalability > testing). Hooray for our friends at Online.net and RunAbove.com for > helping us out! Austin, Any chance you could tell us a little more about these machines, in particular the Arm machines? Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Trouble committing
Herbert Valerio Riedel wrote: > What does the following command output in your case? > > $ git remote show -n origin | grep URL > Fetch URL: git://git.haskell.org/ghc.git > Push URL: ssh://g...@git.haskell.org/ghc.git Fixed it with some help from ezyang who suggested: git remote set-url origin --push ssh://g...@git.haskell.org/ghc.git Cheers, Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Trouble committing
Andreas Voellmy wrote: > Hi GHCers, > > I just fixed a bug (#9423) and went through the Phab workflow. Then I did a > fresh checkout from git and ran: > > $ git checkout master > $ arc patch --nobranch D129 > $ git push origin master > > as explained on https://ghc.haskell.org/trac/ghc/wiki/Phabricator, but on > the last command I get this error: > > fatal: remote error: access denied or repository not exported: /ghc.git > > Maybe I just no longer have commit access to ghc? Andi, Did you get a response to this? I seem to be in the same boat for D570. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: sync-all
Herbert Valerio Riedel wrote: > So I'm not saying `sync-all` is doing something wrong, but rather that's > overly complex for the task at hand, and we've had support issues with > `sync-all` due to subtle bugs in it (just check the git history for > sync-all to see the tweaks we needed). Moreover, IMHO, if someone's > already proficient with Git, telling them to use `sync-all` will rather > confuse than help as it's not that transparent what it really does. So why not turn the current 1000 line Perl script with two lines of shell script and some comments? Erik (who uses sync-all because he didn't know any better) -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory
Mateusz Kowalczyk wrote: > I was told in #ghc that I need to re-run ‘perl boot’ as well. I'll try > it and post back if it still fails. My guess is that the missing 'perl boot' step is what's causing this. When working from the GHC git tree I run 'perl boot' every time I run configure. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory
Mateusz Kowalczyk wrote: > I'm trying to build HEAD but I'm getting > > libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: > HsIntegerGmp.h: No such file or directory > #include "HsIntegerGmp.h" > ^ > compilation terminated. > make[1]: *** > [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1 > make: *** [all] Error 2 > > This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to > build fine before. My last few versions are > > … > drwxr-xr-x5 shana shana 4096 Feb 19 04:45 ghc-20140218 > drwxr-xr-x5 shana shana 4096 Feb 22 22:04 ghc-20140220 > drwxr-xr-x5 shana shana 4096 Feb 25 08:44 ghc-20140225 > > which means that the problem must have been introduced some time after > that point. > > Does anyone have any ideas? What did you do that led up to this point? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changing GHC Error Message Wrapping
Carter Schonwald wrote: > hey andrew, your image link isn't working (i'm using gmail) I think the list software filters out image attachments. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ticket for adding ARM backend to NCG?
Carter Schonwald wrote: > I believe there are no current plans to add arm to the ncg. > > However, I'm hoping to spend a wee bit of time later this year cleaning up Dude, you have 7 days! Or did you mean next year :-). > the ncg, and one consequence of that that simon marlow remarked upon at > icfp is that would perhaps make it easier to add new targets to ncg. As soon as that NCG cleanup is ready for public consumption, please let me know so I can validate the PowerPC NCG. I think I am one of the few people who regularly builds GHC on PowerPC and even I haven't done it for two weeks because I just moved house. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Please help complete `.mailmap`
Herbert Valerio Riedel wrote: > Hello *, > > I've been trying to (re)construct a .mailmap file[1] in ghc.git which > allows `git shortlog` and `git log --use-mailmap` (and possibly other > tools/commands) to fixup bogus author-ids when displaying the Git > history, in the hopes to provide a more complete history of GHC and all > contributors involved. > > I've been able to infer mappings for most users, but I'm stuck on a > couple of older account usernames dating back a decade ago for which I > have no idea what real names to associate with. These are specifically: > 1sseefried Sean Seefried, CC-ed. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Detabbing patch and GHC developers Wiki
p.k.f.holzensp...@utwente.nl wrote: > Dear GHCers, > > Attached is a patch to detab the current HEAD. I applaud your enthusiasm but the GHC developers have decided some time ago that this would not be done as one huge change like you are suggesting. Instead files are de-tabbed when other changes are made to those files and the whitespace/layout fixes are commited separately as explained here: http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git Hope this helps, Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: A build problem on Mac
Kazu Yamamoto (山本和彦) wrote: > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.7.20130907 for i386-apple-darwin): > expectJust block_order Kazu, I'm seeing this on powerpc64-linux: http://ghc.haskell.org/trac/ghc/ticket/8205 There is at least one other report of this happening on OSX. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Compiling GHC with something like distcc?
Hi all, Does anyone have any experience reports on compiling GHC with something like distcc? Don Stewart reports doing it here: http://stackoverflow.com/questions/10323419/is-there-a-distcc-like-tool-for-ghc but there are no detail. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Error on push to GHC git repo due to Trac?
Hi all, Got the error below. Erik bash: warning: setlocale: LC_ALL: cannot change locale (en_AU.UTF-8) Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 412 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_AU.UTF-8) remote: To g...@github.com:ghc/ghc.git remote:9082111..0daee29 master -> master remote: Traceback (most recent call last): remote: File "./hooks/post-receive-trac", line 202, in remote: handle_ref(env=env, *line.split()) remote: File "./hooks/post-receive-trac", line 163, in handle_ref remote: db = env.get_db_cnx() remote: File "/usr/lib/python2.7/dist-packages/trac/env.py", line 329, in get_db_cnx remote: return get_read_db(self) remote: File "/usr/lib/python2.7/dist-packages/trac/db/api.py", line 90, in get_read_db remote: return _transaction_local.db or DatabaseManager(env).get_connection() remote: File "/usr/lib/python2.7/dist-packages/trac/db/api.py", line 152, in get_connection remote: return self._cnx_pool.get_cnx(self.timeout or None) remote: File "/usr/lib/python2.7/dist-packages/trac/db/pool.py", line 227, in get_cnx remote: return _backend.get_cnx(self._connector, self._kwargs, timeout) remote: File "/usr/lib/python2.7/dist-packages/trac/db/pool.py", line 147, in get_cnx remote: raise TimeoutError(errmsg) remote: trac.db.pool.TimeoutError: Unable to get database connection within 0 seconds. (TracError: The user erikd requires read _and_ write permissions to the database file /home/trac/ghc/db/trac.db and the directory it is located in.) To darcs.haskell.org:/srv/darcs/ghc.git 9082111..0daee29 master -> master -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: "~~" in sync-all
Kazu Yamamoto (山本和彦) wrote: > Hi, > > A recent change[1] to sync-all introduces the "~~" operator of > Perl. It seems to me that this operator is not supported by old Perl. > > % perl --version > This is perl, v5.8.8 built for i386-linux-thread-multi > > % ./sync-all -r git://github.com/ghc --testsuite get > syntax error at ./sync-all line 904, near ""pull" ~" > BEGIN not safe after errors--compilation aborted at ./sync-all line 906. > > Sorry for using old Perl but I appreciate if this operator will be > replaced with others. Thanks for the heads up Kazu. Should be fixed in 0daee297e3c44c00f54d2be15f13eabdddc6b62f. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libffi-tarballs
Richard Eisenberg wrote: > After the libffi-tarballs submodule was added, I did a ./sync-all pull, > a ./sync-all get, and a git submodule update. Everything builds just > fine, but I get this answer from git status: > > # On branch master > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # libffi-tarballs/ > nothing added to commit but untracked files present (use "git add" to > track) > > Is this expected? How can I fix this? Richard, I've just added libffi-tarballs to the .gitignore file. That should fix it. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC git server issue : warning: setlocale: LC_ALL: cannot change locale (en_AU.UTF-8)
Hi all, I'm getting the above warning messahe every time I pull from the main GHC git repo. The strange thing is that this only happens on the GHC repo, on a whole bunch of others I get no such warning. After some pretty rigorous investigation I concluded that this is actually a issues with the GHC sit server. Since I'm doing the pull over ssh, ssh passes my environment (include LC_*) to the server, but the server doesn't support en_AU.UTF-8. To explore further, I sshed into darcs.haskell.org and it seems that locales are completely broken on this machine. Not even en_US.UTF-8 is support. I suppose its not a big deal but it would be nice to fix so no one else wastes any time debugging this. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Ian leaving and the glorious future
Vincent Hanquez wrote: > As a suggestion to increase participation, OcamlLab recently hosted a > compiler hacking evening [1] and maybe it would be a good idea to host > the same kind of thing for GHC ? That's a good idea Vincent. > If it's not practical to meet in the > same physical place (not enough people in the same place, no place to > meet, etc), organizing IRC hacking session might a good backup option. Maybe ICFP in Boston in Septemtber? Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libffi
Jan Stolarek wrote: > > Better yet, the sync-all script should detect whether it is on master and > > error out (with a decent error message) if not. > Why? I think it is behaving properly - it fetches master branch from the > server and merges it into > local master branch, just as expected. I imagine that switching to master > branch in all the > subrepos before doing ./sync-all pull will be annoying. Perhaps a warning > will be useful here, > but error seems like too much. I downgraded it to a warning and commited it. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libffi
Patrick Palka wrote:
> I think the branch check should only be done when performing a pull
> command. That way one can still do ./sync-all fetch, ./sync-all diff, etc
> when on a separate branch.
Yes, that makes sense. Updated patch attached.
Cheers,
Erik
--
------
Erik de Castro Lopo
http://www.mega-nerd.com/
>From 00c7fbaf0caff710aa0c48a3e7be564e9a91a728 Mon Sep 17 00:00:00 2001
From: Erik de Castro Lopo
Date: Sun, 4 Aug 2013 16:33:27 +1000
Subject: [PATCH] sync-all : Bail out of 'pull' operation if not on master
branch.
---
sync-all | 14 ++
1 file changed, 14 insertions(+)
diff --git a/sync-all b/sync-all
index fc629df..5da88c7 100755
--- a/sync-all
+++ b/sync-all
@@ -551,6 +551,17 @@ sub gitall {
unlink "resume";
}
+sub assertCurrentBranchIsMaster {
+my $branch = `git symbolic-ref HEAD` ;
+$branch =~ s/refs\/heads\/// ;
+$branch =~ s/\n// ;
+
+if ($branch !~ /master/) {
+die "\nError: You trying to 'pull' while on branch '$branch'.\n"
+ . "To perform a 'pull' you should switch back to the master branch first.\n\n"
+}
+}
+
sub help
{
my $exit = shift;
@@ -889,6 +900,9 @@ sub main {
}
BEGIN {
+if ("pull" ~~ @ARGV) {
+assertCurrentBranchIsMaster();
+}
$initial_working_directory = getcwd();
}
--
1.8.4.rc1
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libffi
Erik de Castro Lopo wrote:
> Simon Peyton-Jones wrote:
>
> > I'd done that (repeatedly). BUT, as has often happened before, I'd
> > forgotten
> > that my tree was on a different branch, and pulling of course has no effect
> > on
> > the branch. Rats. Note to self: whenever anything odd happens, check you
> > are on 'master'.
>
> Better yet, the sync-all script should detect whether it is on master and
> error out (with a decent error message) if not.
>
> That way you (and I and others) don't have to remember this particular failure
> mode.
>
> My Perl coding skills are rather rusty, but I'll have a go at this.
Attached is a patch that checks that the current branch is master
and bails if it isn't. If no one sees anything obviously wrong
with this I'll push it.
Cheers,
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
>From d692f589357337bcc0b9f618306249a1f9ec3c12 Mon Sep 17 00:00:00 2001
From: Erik de Castro Lopo
Date: Sun, 4 Aug 2013 11:56:16 +1000
Subject: [PATCH] sync-all : Bail out if not on master branch.
---
sync-all | 12
1 file changed, 12 insertions(+)
diff --git a/sync-all b/sync-all
index fc629df..6497b95 100755
--- a/sync-all
+++ b/sync-all
@@ -551,6 +551,17 @@ sub gitall {
unlink "resume";
}
+sub assertCurrentBranchIsMaster {
+my $branch = `git symbolic-ref HEAD` ;
+$branch =~ s/refs\/heads\/// ;
+$branch =~ s/\n// ;
+
+if ($branch !~ /master/) {
+die "\nError: You are currently on branch '$branch'.\n"
+ . "Switch back to master to run 'sync-all'.\n\n"
+}
+}
+
sub help
{
my $exit = shift;
@@ -889,6 +900,7 @@ sub main {
}
BEGIN {
+assertCurrentBranchIsMaster();
$initial_working_directory = getcwd();
}
--
1.8.4.rc1
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libffi
Simon Peyton-Jones wrote: > | I think you need to do a 'git pull' first to get the latest version of the > | sync-all script and when you run that you should get a libffi-tarballs > > I'd done that (repeatedly). BUT, as has often happened before, I'd forgotten > that my tree was on a different branch, and pulling of course has no effect on > the branch. Rats. Note to self: whenever anything odd happens, check you > are on 'master'. Better yet, the sync-all script should detect whether it is on master and error out (with a decent error message) if not. That way you (and I and others) don't have to remember this particular failure mode. My Perl coding skills are rather rusty, but I'll have a go at this. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libffi
Simon Peyton-Jones wrote: > But ./sync-all get doesn't get a libffi repo. Nor is it listed in ./packages. > > Does anyone have any idea where this new libffi repo is, and why it isn't > listed? Simon, I think you need to do a 'git pull' first to get the latest version of the sync-all script and when you run that you should get a libffi-tarballs directory. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Feature Request : Qualified module exports
David Luposchainsky wrote: > I'm not sure this is such a good idea. > > Haskell's namespace system happens strictly during import - the importer > chooses what name to use, and a module has no influence on how it will > be referred to by other modules. > > On the other side, there's the C++-like namespace system, where each > function is defined as part of some namespace, leading to the > "qualification" during export. In other words, if foo is defined in > namespace bar, you will always have to refer to it as bar::foo. > > The proposal blurs the line between these two - a module can specify > under what qualified name another module is imported. Just about any language feature can be abused in some way. This proposal can also be misused, but can be extremely beneficial in a number of very common use cases. There is a huge amount of existing code out there that does one or more of the following two: import qualified Data.ByteString.Char8 as BS8 import qualified Data.Text as T with every module using those modules having the exact same two lines of code. My code already has a custom Prelude which drops some dangerous functions (head/tail etc) and adds types Text, ByteString and a couple of my own functions. For my current project, qualified exports would remove the above two lines from about 50 files. If this feature was only enabled with a -XQualifiedModuleExports pragma, would that decrease your objection? Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Feature Request : Qualified module exports
Hi all, I've added a feature request ticket to the GHC trac: http://ghc.haskell.org/trac/ghc/ticket/8043 for qualified module exports. In a nutshell this would allow the following 'qualified module' export eg: module MyModule ( qualified module T ) import qualified Data.Text as T so that any module which imports MyModule has access to the symbols of Data.Text under the quaified module name T. This feature actually looks like something which I'm capable of undertaking so if nobody thinks this is a really bad idea, I'll have a crack at this. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Running GHC Tests for Cross-Compiler?
Stephen Paul Weber wrote: > Anyone know the best way to build the GHC test suite so that it can be run > on another device (so that I can run them for my cross-compiler)? I can't answer the question for GHC, but for one of my projects (libsndfile) I have make target that builds a testsuite binary tarball which includes all the test programs (as binaries), the required test data and a single script to run the whole test suite. Works like a charm. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Updated wiki docs in Type representation.
Hi all, I was reading the GHC compiler commentary and the current GHC sources and found that description here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/TypeType#TherepresentationofType did not match the code in Git. I edited the wiki to the best of my ability but would appreciate it if someone who understands this better could have a look over it hopefully improve it. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: how to checkout proper submodules
David Terei wrote: > Either way, I'm glad git bisect may soon work. Having git bisect work on the GHC tree would be a plus! Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC plugin without registering the plugin
Hi all, I'm messing about with writing a GHC plugin and looking at the documentation here: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/compiler-plugins.html which states: Plugins can be specified on the command line with the option -fplugin=module where module is a module in a registered package that exports a plugin. Is there anyway I can have a plugin in my local source tree rather than being installed and registered? Not having to cabal install it would make development and debugging somewhat easier. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
