The dreaded windows path length issue
Hi all, I'm now working for IOHK on the Cardano project. The Cardano code base is large and we are hitting the dreaded windows path length bug. We have already shortned build paths as much as possible but are still hitting this We're currently using ghc-8.0.2 but even ghc-8.2.2 has this issue. A snippet of the logs in included below. I took the liberty of including Tamar on this since he is the known Windows expert. Not having a local Window makes this really difficult to debug. Anyone have any solutions for this? I'm willing to backport patches if needed. I've managed to find a VirtualBox evaluation image on the Microsoft site. Hopefully that will give me enough to debug this issue. Cheers, Erik [01:27:27] -- While building custom Setup.hs for package csl-wallet-new-1.1.1 using: [01:27:27] C:\s\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.w\dist\5c8418a7 build lib:csl-wallet-new exe:cardano-node exe:csl-gen-swagger exe:csl-integ-test test:wallet-new-specs test:wallet-unit-tests --ghc-options " -ddump-hi -ddump-to-file" [01:27:27] Process exited with code: ExitFailure 1 [01:27:27] Logs have been written to: C:\w\.w\logs\csl-wallet-new-1.1.1.log [01:27:27] [01:27:27] Configuring csl-wallet-new-1.1.1... [01:27:27] Preprocessing library for csl-wallet-new-1.1.1.. [01:27:27] Building library for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Linking .w\dist\5c8418a7\build\csl-integ-test\csl-integ-test.exe ... [01:27:27] realgcc.exe: error: CreateProcess: No such file or directory [01:27:27] `gcc.exe' failed in phase `Linker'. (Exit code: 1) [01:27:27] Command "call stack --dump-logs install cardano-sl cardano-sl-tools csl-wallet csl-wallet-new -j 2 --no-terminal --local-bin-path c:\w --test --no-haddock-deps --flag cardano-sl-core:-asserts --flag cardano-sl-tools:for-installer --flag csl-wallet:for-installer --extra-include-dirs="C:\OpenSSL-Win64-v102\include" --extra-lib-dirs="C:\OpenSSL-Win64-v102" --extra-include-dirs="C:\xz_extracted\include" --extra-lib-dirs="C:\xz_extracted\bin_x86-64" --extra-include-dirs="c:\w\rocksdb\include" --extra-lib-dirs="c:\w"" failed with exit code 1. Retrying 4 of 5 -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: How to get a heap visualization
Ben Gamari wrote: > Yitzchak Gale <g...@sefer.org> writes: > > > Joachim, first and foremost, thanks for the awesome libraries > > ghc-vis and ghc-heap-view. > > > > The design trade-offs for ghc-vis do make sense if you think of > > it as a didactic tool. But as a debugging tool, the most important > > factor is that it should "Just Work", with no big builds, no fiddling, > > no googling. When you reach for a debugging tool, you are > > *already* in a debugging situation; you don't have patience > > for also debugging the tool. > > > I should point out that there is a differential (D3055) by erikd from > earlier this year which folded ghc-heap-view into GHC. The goal was to > make heap-view a supported library which could be relied upon by third > party tools. As far as I can remember most of the hard work is done; it > just needed some finishing touches. Perhaps you would be interested in > picking it up? Sorry if I gave the wrong impression, but IMO ghc-heap-view is a *long* way from being ready to integrate into GHC. ghc-heap-view currently supports most of the normal/simple heap object types. but has no support for more complex objects. Furthermore, levity polymorphism adds a whole new dimension to the problem. My estimate of the amount of work required to make ghc-heap-view cover all the heap objects was such that I abandoned the project. I would love to see someone pick it up and run with it. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Rewrite rules
Joachim Breitner wrote:
> very little. The best one can do right now is to know enough about Core
> and the inliner to predict when things are going to be inlined and when
> not, what else can go wrong (wrappers maybe?), add the necessary
> controls (`NOINLINE [0]` etc.), and then hope for the best. And track
> down any instances of failed rewriting that you learn about.
>
> You might also be able to set up your code so that it fails (at
> runtime, with error) if the desired rules did not fire. This would be
> nicer if we had https://ghc.haskell.org/trac/ghc/ticket/9180.
>
> You can also ask for review if it is public code.
Ok, I'm heading in this direction and then I figure out that the parser
for the rewrite rules doesn't even reject obvious syntax errors.
Say I have a data types:
data Word128 = Word128 Word64 Word64
and inspired by the `fromIntegral` rules for Word64 I write:
{-# RULES
"fromIntegral/Word64->Word128" fromIntegral = \w64 -> Word128 0 w64
#-}
all is fine and dandy. However if I introduce an obvious syntax error
like reversing the `->`:
{-# RULES
"fromIntegral/Word64<-Word128" fromIntegral = \w64 -> Word128 0 w64
#-}
I don't get any warning or anything. I've read the docs for rewrite
rules:
https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html#rewrite-rules
but they are rather sparse and again are very short on guarantees.
Have I just managed to find myself a new project?
Erik
--
----------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Rewrite rules
Michael Snoyman wrote: > Could be I'm misunderstanding, but are you looking for -ddump-rule-firings? Wasn't aware of that, but my question was a little more general. If I write a library that includes rewrite rules, how can I ensure that they fire in client code that someone else writes? What guarantees (however loose) are there? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RFC: Removing the `-hb` profiling option
Hi all, After a bit of rather tedious and frustrating debugging I came to the realisation that the code for the `-hb` profiling option is not thread safe. See https://ghc.haskell.org/trac/ghc/ticket/12019 This gives us an opportunity to simply remove it instead of fixing it. If there is anyone that thinks this future is really useful (ie more useful than the other profiling modes) then I'm willing to fix it. But if noone would miss it. I'd much rather remove it. Thoughts? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Looking for GHC compile-time performance tests
Ben Gamari wrote: > So, if you would like to see your program's compilation time improve > in GHC 8.2, put some time into reducing it to something minimal, submit > it to us via a Trac ticket, and let us know in this thread. The vector package is probably a good candidate. Compling vector slowed down signicantly between 7.8 and 7.10, only to speed up again with 8.0. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
Evan Laforge wrote: The recent release of ghc 7.10.2 reminded me of something I meant to ask about a long time ago. Most of the binaries ghc installs are versioned (x linked to x-7.10.2), with some exceptions (hpc and hsc2hs). Shouldn't they all be versioned? Also, 'haddock' is inconsistent with all the rest, in that it's haddock linked to haddock-ghc-7.10.2. I maintaing multiple versions of GHC on all the machines I use regularly for Haskell development. I have: * ghc-7.6.3 installed under /usr/lib/ghc-7.6/ * ghc-7.8.4 installed under /usr/lib/ghc-7.8/ * ghc-7.10.2 installed under /usr/lib/ghc-7.10/ To switch between versions all I need to do is modify $PATH to remove say /usr/lib/ghc-7.6/bin and add /usr/lib/ghc-7.10/bin. This lets me have two terminal window side by side with different versions of GHC. I actually have a shell function to to do this PATH mangling. I can document this more fully if anyone is interested. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
Wolfram Kahl wrote: I use essentially the same setup, but found that cabal-install does not play nicely with this: No matter under which prefix I install cabal-install, it always assumes the same global path for its configuration file. I install cabal-install from debian which just puts it in /usr/bin/ which works fine, with and without sandboxes. This is a nuisance in particular when for some reason different versions of GHC need different versions of cabal-install --- apparently older GHCs don't work with newer versions of cabal-install? I have not run into this problem with ghc-7.6.3, ghc-7.8.4 and ghc-7.10.2 installed. I did experiment with cabal-install's -w and sandboxes, and agree with what was previously mentioned: It only helps if you never use GHC without cabal-install. With a recent version of cabal, run 'cabal user-config diff' to display what if different between your ~/.cabal/config and what cabal would install if it didn't exist. Sometimes an older ~/.cabal/config file can cause troubles. Cheers, Erik PS: Please reply to the list and do not CC me. -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Defining a custom newByteArray primop that uses calloc?
Brandon Simmons wrote: In my tests, using calloc from: https://hackage.haskell.org/package/missing-foreign-0.1.1/docs/Foreign-Marshal-MissingAlloc.html was about twice as fast as allocating and zeroing the same amount of memory with `newByteArray` + any of `copy/set/fillMutableByteArray` (all three were nearly identical). Is there a way I can reasonably define my own `newByteArray` that uses calloc? FWIW here are a couple of the benchmarks I'm working with in criterion: arrTestSet :: Int - IO () arrTestSet len = do let eBytes = (P.sizeOf (undefined::Int))*len a - P.newAlignedPinnedByteArray Why pinned memory? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond
Michael Snoyman wrote: On Tue, Apr 1, 2014 at 8:07 AM, Kazu Yamamoto k...@iij.ad.jp wrote: Hi Gershom, We've also seen a lot of interest in distribution and cloud computing. From the articles I've read, efficient concurrent programming involves using node.js, so I think we should put some work into writing a new-new-new-IO Manager built on top of this technology. As a member of Mio developers, I don't understand this sentence. Would you concretely explain what kind of node.js technologies should be taken into new-new-new-IO Manager? It's really simple: node.js is webscale, Mio is not. I'm sorry, but you simply didn't do a good enough job making sure that random packets were lost when sending network traffic, or that writing data to disk may sporadically fail. Better luck next time. I think Michael about sums it up. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RC2 build failures on Debian: sparc
Joachim Breitner wrote: sparc fails differently than in RC1, and very plainly with a segmentation fault in dll-split (which happens to be the first program to be run that is compiled with stage1): https://buildd.debian.org/status/fetch.php?pkg=ghcarch=sparcver=7.8.20140228-1stamp=1393975264 Any ideas? Anyone feeling responsible? It would be shame to loose a lot of architectures in 7.8 compared to 7.6, but I’m not a porter and don’t know much about these part of the compiler, so I have to rely on your support in fixing these problems, preferably before 7.8.1. I've seen this on powerpc64 as well, but I first ran into this well before 7.8.1. See: https://ghc.haskell.org/trac/ghc/ticket/8024 Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Mathieu Boespflug wrote: [Sorry for the multiple reposts - couldn't quite figure out which email address doesn't get refused by the list..] Hi Carter, thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? Indeed, this could be done without touching the compiler at all. We had this response really early on in this discussion. Quite honestly I think that should have been the end of the discussion. The existing GHC release already have a huge workload getting releases out the door and adding to that workload without adding manpower and resources would be a bad idea. You really should try doing this as a library outside of GHC and if GHC needs a few small additional features, they can be added. The `static e` form could as well be a piece of Template Haskell, but making it a proper extension means that the compiler can enforce more invariants and be a bit more helpful to the user. Once it works outside GHC and has proven useful, then it might be worthwhile add small specific, easily testable/maintainable features to GHC to support what goes on on your library. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
Carter Schonwald wrote: that still requires some discovery though! The idea (i'd hope) would be to make the my first ghc install on a vm (for experts and new folks both) go from #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make install PREFIX=yah #figure out how to install cabal, eg discover wget and then ./bootstrap # cabal install thingsIwannaTry to # install ghc via some wget and make #cabal install nice things Thats basically how I work on Debian based Linux systems: # apt-get install ghc alex happy cabal-install $ cabal install nice-things Where '#' is the root prompt and '$' is the user prompt. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Parallel building multiple targets
John Lato wrote: ghc --make doesn't allow building several binaries in one run, however if you use cabal all the separate runs will use a shared build directory, so subsequent builds will be able to take advantage of the intermediate output of the first build. As long as the ghc-options flags are the same for all the different component sections (I've been bitten by this). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linux deployment requirements for GHC-produced binaries
Brandon Allbery wrote: On Thu, Oct 3, 2013 at 1:10 PM, Yitzchak Gale g...@sefer.org wrote: ldd just says not a dynamic executable. o.O I don't think the ghc runtime uses dlopen() to get at gmp (and I'm not sure that would even work in a static binary). You may need to resort to strace to find out what's trying to pull in libgmp.so.whatever. Unless this program is like xmonad and requires ghc behind the scenes to build something, in which case you would indeed need everything that ghc requires (and, of course, ghc itself). I suspect the OP's exectuable is aleady being compiled static. For the webapp I'm currently working on I get: ldd test-webapp linux-vdso.so.1 (0x7fffcdd91000) libpq.so.5 = /usr/lib/libpq.so.5 (0x7f973e0a8000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f973de9) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f973dc87000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f973da84000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f973d88) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f973d663000) libldap_r-2.4.so.2 = /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x7f973d412000) liblber-2.4.so.2 = /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x7f973d203000) libgmp.so.10 = /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f973cf8a000) libffi.so.6 = /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7f973cd82000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f973ca84000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f973c6d7000) libssl.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x7f973c479000) libcrypto.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7f973c087000) libkrb5.so.3 = /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f973bdb2000) libcom_err.so.2 = /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f973bbae000) libgssapi_krb5.so.2 = /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f973b96f000) /lib64/ld-linux-x86-64.so.2 (0x7f973e2f9000) libresolv.so.2 = /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f973b757000) libsasl2.so.2 = /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x7f973b53c000) libgnutls.so.26 = /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x7f973b27c000) libgcrypt.so.11 = /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x7f973affc000) libk5crypto.so.3 = /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7f973add3000) libkrb5support.so.0 = /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f973abc9000) libkeyutils.so.1 = /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7f973a9c5000) libtasn1.so.3 = /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x7f973a7b3000) libp11-kit.so.0 = /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7f973a593000) libgpg-error.so.0 = /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7f973a38e000) and libgmp is clearly listed in that. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Tagging subjects of emails sent from the list
Johan Tibell wrote: I'd prefer if they weren't tagged. My mail reader (GMail) can do the tagging for me and I'll end up with duplicated tags and the list of subjects get harder to scan. I'm with Johan. I have tools to sort the list mail and would prefer not to have redundant stuff obscuring the subject line. I see you're using KMail. Surely that has automatic filtering facilities? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter
Carter Schonwald wrote: hey all, It seems to me (and i've certainly heard other people echo this sentiment) that: ghc dev chatting gets buried in the huge volume of commit + build report emails, and that creates (perhaps) another barrier to involvement in ghc dev at the hobbyist (rather than part time/full time ) scale? So my question for the community (and of course current ghc devs ) 1) do others agree that theres value in separating the two? 2) would this just be another use of the ghc-users list or would it be worth having a ghc-dev list? 3) most importantly, would the folks actively involved in ghc dev be willing/able to do so? +1 This is a good idea, one that I have solved at my end using Procmail. So even though I have solved it for me, I still approve of this suggestion since it seems silly to push this to the receiver's end when it could so easily be solved by having separate lists. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.1 Release Candidate 1
Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 7.6.1: http://www.haskell.org/ghc/dist/7.6.1-rc1/ This includes the source tarball, installers for 32bit and 64bit Windows, and bindists for amd64/Linux, i386/Linux, amd64/OSX and i386/OSX. Please test as much as possible; bugs are much cheaper if we find them before the release! On PowerPc I get this: compiler/nativeGen/X86/Regs.hs:61:1: Warning: The import of `CmmCallConv' is redundant except perhaps to import instances from `CmmCallConv' To import instances alone, use: import CmmCallConv() which in HEAD was fixed by the application of this patch: commit 2f7c578574a9d5e9b4d95847abc3d1cb1b35336d Author: Erik de Castro Lopo er...@mega-nerd.com Date: Wed Aug 8 06:44:00 2012 +1000 Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC ARM builds?
Karel Gardas wrote: Last note: GHC/ARM depends on GHC's specific calling convention support in LLVM. Unfortunately for ARM platform it was merged into LLVM 3.0, but not into LLVM HEAD (at that time), so LLVM 3.1 doesn't support GHC/ARM at all. I'm trying to resubmit the support for inclusion here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/051119.html -- but it's still not merged in. Karel, its probably time you pinged them again asking for that to be merged :-). Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC ARM builds?
Austin Seipp wrote: With 7.4.2, the patches for full ARM linker support were merged and released. Are there any official builds of GHC for Linux/ARM yet? I have a PandaBoard ES I'd be willing to contribute for builds and/or testing/development, but I don't know where to get a GHC for bootstrapping. It's also worth asking if there's any page documenting needed prerequisites/expected build environment. If not it should be added to the wiki (I don't see any as of right now.) I'm not sure what linux distro you're rinning on that, but if you run Debian (probably also Ubuntu) then you can apt-get a working GHC. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Using 'git bisect' on the GHC tree
Hi all, I am trying to track down a build failure on PowerPC that was introduced some time this year. Usually, the easiest way to do this is by using 'git bisect'. Unfortunately, this doesn't work with the GHC tree since its easy to go to a GHC revision which is incompatible with one of the many GHC sub-modules (eg Cabal). Given a GHC git commit hash, is there a way to get the various libraries into a state where I can build the GHC version specified by the hash? Regards, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using 'git bisect' on the GHC tree
Erik de Castro Lopo wrote: Given a GHC git commit hash, is there a way to get the various libraries into a state where I can build the GHC version specified by the hash? As suggested by this: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystate and some help from Igloo on #ghc, I grabbed a build log from http://darcs.haskell.org/ghcBuilder/builders/tn23/534/4.html and generated a fingerprint file from that. I then did ./utils/fingerprint/fingerprint.py restore -f tn23build534.fp and tried to build it, but was still thwarted by the following: Configuring Cabal-1.13.3... ghc-cabal: At least the following dependencies are missing: base =4 3 =2 5, filepath =1 1.3 make[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1 make: *** [all] Error 2 At this point I think I basically have to give up on using git bisect which I have found so useful on other projects. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Implementing a New primop
Antoine Latter wrote: Hi Paul, The ghc-users list might get you a quicker response to this sort of question. I thing ghc-cvs might be even better :-). Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
