May 2015 - ghc-devs - Haskell.org

RE: vectorisation code?
by Simon Peyton Jones 12 Sep '16

12 Sep '16

Austin, (or anyone else) Manuel says: | > Would it be ok if we left it in the repo, but CPP'd it out so that | we | > didn't compile everything? (The DPH library is in the same state at | > the moment.) | > | > It might suffer bit-rot, but it’d still be there for resurrection. | | Sure, that’s ok. Could you action this? Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary. Leave enough comments to explain! Simon | | I hope everything is fine in Cambridge! | Manuel | | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Manuel M T Chakravarty | > | Sent: 16 January 2015 02:58 | > | To: Richard Eisenberg | > | Cc: ghc-devs(a)haskell.org Devs | > | Subject: Re: vectorisation code? | > | | > | [Sorry, sent from the wrong account at first.] | > | | > | We currently don’t have the resources to work on DPH. I would | > | obviously prefer to leave the code in, in the hope that we will be | > | able to return to it. | > | | > | Manuel | > | | > | > Richard Eisenberg <eir(a)cis.upenn.edu>: | > | > | > | > Hi devs, | > | > | > | > There's a sizable number of modules in the `vectorise` | > | subdirectory of GHC. I'm sure these do all sorts of wonderful | > | things. But what, exactly? And, does anyone make use of these | wonderful things? | > | > | > | > A quick poking through the code shows a tiny link between the | > | vectorise code and the rest of GHC -- the function `vectorise` | > | exported from the module `Vectorise`, which is named in exactly | one | > | place from SimplCore. From what I can tell, the function will be | > | called only when `-fvectorise` is specified, and then it seems to | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is | > | given only a cursory explanation. It seems these work with DPH... | > | which has been disabled, no? Searching online finds several hits, | > | but nothing more recent than 2012. | > | > | > | > I hope this question doesn't offend -- it seems that | > | vectorisation probably has amazing performance gains. Yet, the | > | feature also seems unloved. In the meantime, compiling (and | > | recompiling, and | > | recompiling...) the modules takes time, as does going through | them | > | to propagate changes from elsewhere. If this feature is truly | > | orphaned, unloved, and unused at the moment, is it reasonable to | > | consider putting it on furlough? | > | > | > | > Thanks, | > | > Richard | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs

13 35

arc land changes author
by Joachim Breitner 19 Dec '15

19 Dec '15

Hi, I was just about to apply a DR by David. First I ran $ arc patch D390 which put me on a feature branch. Then I reworded the commit with $ git commit --amend and then I tried to land it with $ arc land Luckily I also passed --hold... It even asked me if I want to land the commit although I am not the author: This branch has revision 'D390: Reorder GHC.List; fix performance regressions' but you are not the author. Land this revision by dfeuer? [y/N] y But it still put me in the author field: $ git show HEAD commit a387c359b99667ce55016de3816b5d9873a155db Author: Joachim Breitner <mail(a)joachim-breitner.de> Date: Wed Oct 29 08:17:05 2014 +0100 Reorder GHC.List; fix performance regressions Summary: Rearrange some oddly placed code. (and undid my commit message changes....) Did I do something wrong? Anyways, it said something along the lines of Cleaning up feature branch... (Use `git checkout -b 'arcpatch-D390' 'a3ceb0e7f44d53f728fb8bd0dfb4c97297818029'` if you want it back.) so with $ git commit --amend -C a3ceb0e7f44d53f728fb8bd0dfb4c97297818029 I was able to get the edited commit message with the right author back. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2

utils/hp2ps/Main.c:88: possible missing break ?
by David Binderman 15 Sep '15

15 Sep '15

Hello there, [utils/hp2ps/Main.c:88] -> [utils/hp2ps/Main.c:91]: (warning) Variable 'iflag' is reassigned a value before the old one has been used. 'break;' missing? Source code is switch( *(*argv + 1) ) { case '-': iflag = -1; case '+': default: iflag = 1; } Suggest add missing break. Regards David Binderman

2 1

Cabal and simultaneous installations of the same package
by Simon Peyton Jones 29 Aug '15

29 Aug '15

Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon

11 21

Backporting srcLoc to the GHC 7.10 branch
by Michael Snoyman 15 Jul '15

15 Jul '15

It looks like the srcLoc change[1] is something that some of our (FP Complete's) customers would be quite interested in getting access to sooner rather than later. Would there be any possibility of getting that patch merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at actually including it in 7.10.1, but would it be on the table for 7.10.2? We do of course have the option of backporting it ourselves and including it in a custom GHC we provide customers, but we generally try to stay as close to upstream as possible. [1] https://ghc.haskell.org/trac/ghc/ticket/9049

9 20

Right way to turn off dynamic linking in build.mk
by Johan Tibell 07 Jul '15

07 Jul '15

Some times when I play around with GHC I'd like to turn off dynamic linking to make GHC compile faster. I'm not sure what the right way to do this in build.mk. It's made confusing by the conditional statements in that file: GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) This line make me worry that if I don't put DYNAMIC_GHC_PROGRAMS = NO in the right place in build.mk it wont "take". There's also this one: ifeq "$(PlatformSupportsSharedLibs)" "YES" GhcLibWays += dyn endif Seeing this makes me wonder if DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO is enough or if the build system still sniffs out the fact that my platform supports dynamic linking. Could someone please give an authoritative answer to how to turn off dynamic linking? -- Johan

4 5

RFC: "Native -XCPP" Proposal
by Herbert Valerio Riedel 19 Jun '15

19 Jun '15

Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out). So please go ahead and read the Wiki page... and then speak your mind! Thanks, HVR [1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics?

15 19

MSYS2 package for GHC 7.10.1
by David Macek 04 Jun '15

04 Jun '15

Hi everyone. After finally putting some uninterruped effort into it, I managed to create (hopefully) working prototypes of two GHC-related packages for MSYS2, namely ghc[1] and cabal-install[2]. I've prepared recipes (PKGBUILDs) for building from source, but 64-bit binaries[5][6] are also provided for those who'd like to test my build without building it themselves. With this post, I'd like to start some work towards the following goals (I hope we can get some Windows discussion going again): - verify that the build is reproducible (see below for instructions) - make tests pass - fix known issues (see below for list) - discover and fix unknown issues - review and upstream as many patches as possible - make it easier for people on Windows to start hacking on GHC I'll be glad to read any responses, notes, results, hints, comments and/or criticisms. Please note that I'm writing this after being submerged in the matter for some time, so don't be surprised to see any glaring omissions or obvious mistakes. Known issues ============ Configure has a problem with docbook - This mean Haddock is not built. It's probably some silliness on the part of MSYS2's docbook. Integer-gmp object file has a reference to __mingw_vsnprintf - Compiling seems to work fine, presumably because the final link command includes -lmingwex, but `runhaskell Setup.lhs` in the text package source tree gave me an undefined reference error, causing inability to load integer-gmp module. I don't know where to start fixing this, as I have not yet reached the depth of understanding of GHC source needed for that. Wildly untested - I didn't try building with LLVM and the testsuite is currently failing to start, giving some weird errors. Trying cross compiling or compiling a cross compiler didn't even cross my mind (har har). Patches ======= A lot of the patches deal with the directory structure -- I tried to mirror the common FHS layout as closely as possible while still retaining the advantages of relocatability. I also removed the bundled toolchain and perl, in favor of packages included with MSYS2. I assume these changes are somewhat controversial for upstreaming, but it'd be nice to see the official bindists to adopt this layout. There are several patches that I think are more of straight-forward fixes rather than design changes, namely numbers 0007, 0010, 0014 and 0015. Build instructions ================== General build instructions[3] are available at our wiki. For convenience, I've compiled a sequence of commands that should get you the ghc and cabal-install packages, given that you start with an up-to-date installation of MSYS2 and a working GHC in PATH. Refer to our guide[4] for correct way of getting/upgrading your MSYS2. ## start MSYS2 shell pacman --needed -S base-devel mingw-w64-x86_64-toolchain mingw-w64-i686-toolchain git clone https://github.com/elieux/mingw-packages cd mingw-packages git checkout ghc pushd mingw-w64-ghc makepkg-mingw -sLf pacman -U mingw-w64-*-ghc-*-any.pkg.tar.xz ## remove old GHC from PATH popd pushd mingw-w64-cabal-install makepkg-mingw -sLf pacman -U mingw-w64-*-cabal-install-*-any.pkg.tar.xz popd If you prefer to build only for one architecture, export a variable named MINGW_INSTALLS with a value of "mingw32" or "mingw64" before building. == [1] https://github.com/elieux/mingw-packages/tree/ghc/mingw-w64-ghc [2] https://github.com/elieux/mingw-packages/tree/ghc/mingw-w64-cabal-install [3] http://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/ [4] http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ [5] https://dl.dropboxusercontent.com/u/59899181/mingw-w64-x86_64-cabal-install… [6] https://dl.dropboxusercontent.com/u/59899181/mingw-w64-x86_64-ghc-7.10.1-1-… -- David Macek

3 5

Consecutive FFI calls
by David Turner 03 Jun '15

03 Jun '15

Hi, If I make a sequence of FFI calls (on a single Haskell thread) but which end up being called from different OS threads, is there any kind of ordering guarantee given? More specifically, is there a full memory barrier at the point where a Haskell thread migrates to a new OS thread? Many thanks, David

3 5

API to “raise concern” in Phabricator
by Joachim Breitner 03 Jun '15

03 Jun '15

Hi, with https://perf.haskell.org/ghc/ up and running I’m wondering about the best way to notify us about regressions. A mail to ghc-commits is one possibility, but maybe it’s neater to integrate that into Phabricator. How hard would it be comment and optionally “raise concern” with a commit automatically? Or, put differently, I want a script that takes a git commit, a comment, and a flag that indicated whether a concern should be raised, and then does that on Phabricator. It seems that https://phabricator.haskell.org/conduit/ is an entry point, but I only see methods for attaching comments to DRs. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1