September 2015 - ghc-devs

ArrayArrays
by Edward Kmett 08 Sep '15

08 Sep '15

Would it be possible to add unsafe primops to add Array# and SmallArray# entries to an ArrayArray#? The fact that the ArrayArray# entries are all directly unlifted avoiding a level of indirection for the containing structure is amazing, but I can only currently use it if my leaf level data can be 100% unboxed and distributed among ByteArray#s. It'd be nice to be able to have the ability to put SmallArray# a stuff down at the leaves to hold lifted contents. I accept fully that if I name the wrong type when I go to access one of the fields it'll lie to me, but I suppose it'd do that if i tried to use one of the members that held a nested ArrayArray# as a ByteArray# anyways, so it isn't like there is a safety story preventing this. I've been hunting for ways to try to kill the indirection problems I get with Haskell and mutable structures, and I could shoehorn a number of them into ArrayArrays if this worked. Right now I'm stuck paying for 2 or 3 levels of unnecessary indirection compared to c/java and this could reduce that pain to just 1 level of unnecessary indirection. -Edward

9 46

Shared data type for extension flags
by Michael Smith 08 Sep '15

08 Sep '15

#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from DynFlags to the user. There is a second data type encoding the list of possible language extensions in the Cabal package, in Language.Haskell.Extension [3]. But template-haskell doesn't already depend on Cabal, and doing so seems like it would cause difficulties, as the two packages can be upgraded separately. So adding this new feature to Template Haskell requires introducing a *third* data type for language extensions. It also requires enumerating this full list in two more places, to convert back and forth between the TH Extension data type and GHC's internal ExtensionFlag data type. Is there another way here? Can there be one single shared data type for this somehow? [1] https://ghc.haskell.org/trac/ghc/ticket/10820 [2] https://phabricator.haskell.org/D1200 [3] https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ex…

6 9

Cannot have GHC in ARMv6 architecture
by jmcf125＠openmailbox.org 07 Sep '15

07 Sep '15

Hi, I have tried to have GHC in my Raspberry Pi, got stuck in the issue 7754 (https://ghc.haskell.org/trac/ghc/ticket/7754) since I didn't know where to pass options to terminfo's configure file, although I did copy the headers from my Raspberry Pi. I've been using HUGS ever since, as Arch Linux doesn't have GHC for ARMv6, and deb2targz would not work. I'm aware I have a phase 0 compiler installed, need to build a phase 1 compiler, and use that to cross-compile GHC itself (I wasn't the 1st time I tried, couldn't find as much information as now). I've read the following pages: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation along with quite a few bug reports, and questions on Stack Overflow that seemed related but really aren't, or that are already exposed in the tickets mentioned below. Below, /home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/include-curses and /home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/lib-curses are directories to which I copied any headers and libraries, respectively, from my Raspberry Pi. I'm not sure which libraries I am supposed to point configure at. These are the headers-libraries combinations I tried: $ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/include-curses --with-curses-libraries=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/lib-curses && make -j5 (...) checking for unistd.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking curses.h usability... no checking curses.h presence... no checking for curses.h... no configure: error: in `/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo': configure: error: curses headers could not be found, so this package cannot be built See `config.log' for more details libraries/terminfo/ghc.mk:4: recipe for target 'libraries/terminfo/dist-install/package-data.mk' failed make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 (https://ghc.haskell.org/trac/ghc/ticket/7754) $ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/usr/include --with-curses-libraries=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/lib-curses && make -j5 (...) checking for unistd.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for setupterm in -ltinfo... no checking for setupterm in -lncursesw... no checking for setupterm in -lncurses... no checking for setupterm in -lcurses... no configure: error: in `/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo': configure: error: curses library not found, so this package cannot be built See `config.log' for more details libraries/terminfo/ghc.mk:4: recipe for target 'libraries/terminfo/dist-install/package-data.mk' failed make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 (https://ghc.haskell.org/trac/ghc/ticket/7281) $ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/usr/include --with-curses-libraries=/usr/lib && make -j5 <OR> $ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/include-curses --with-curses-libraries=/usr/lib && make -j5 (...) Configuring terminfo-0.4.0.1... configure: WARNING: unrecognized options: --with-compiler, --with-gcc checking for arm-unknown-linux-gnueabihf-gcc... /home/jmcf125/ghc-raspberry-pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc checking whether the C compiler works... no configure: error: in `/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo': configure: error: C compiler cannot create executables See `config.log' for more details libraries/terminfo/ghc.mk:4: recipe for target 'libraries/terminfo/dist-install/package-data.mk' failed make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 77 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Concerning the last 2, it'd be odd if they worked, how could, say, the GCC cross-compiler for ARM use x86_64 libraries? I tried them anyway, since the 1st 2 errors didn't seem to make sense... Also, options --includedir and --oldincludedir seem to have no effect (always get issue 7754), and it doesn't matter if I build registarised or not, the results are the same (registarised, I'm using LLVM 3.6.2-3). I'm sorry if I'm wasting your time with what to you might seem such a simple thing, and not real development on GHC, but I don't know where else to turn to. I'm still learning Haskell, and have never had to compile compilers before. Thank you in advance, João Miguel

2 1

Thanks to Reid and Thomas
by Simon Peyton Jones 07 Sep '15

07 Sep '15

Thomas, Reid, As I get back from ICFP, I’d like to take the opportunity to thank you for huge amount of work that you two personally have put into GHC recently. Your interventions are always thoughtful, supportive, and on target. GHC is a huge project, and lots of people contribute to it. I am truly grateful to all of them. But you two have been particularly active in the last year and I wanted to say thank you. Onward and upward, Simon

3 3

Proposal: Argument Do
by Andrew Gibiansky 05 Sep '15

05 Sep '15

Trac: https://ghc.haskell.org/trac/ghc/ticket/10843 I would like the following to be valid Haskell code: main = when True do putStrLn "Hello!" Instead of requiring a dollar sign before the "do". This would parse as main = when True (do putStrLn "Hello!") Has this been tried before? It seems fairly simple -- is there some complexity I'm missing? I've always been confused as to why the parser requires `$` there, and I've heard a lot of others ask about this as well. Perhaps we could fix that? PS. Regardless of whether this goes anywhere, it was fun to learn how to hack on GHC. It was surprisingly easy; I wrote up my experience here <http://rawgit.com/gibiansky/4c54f767bf21a6954b23/raw/67c62c5555f40c6fb67b12…>. The GHC wiki is outstanding; pretty much every intro question about ghc development I had was answered on a fairly easy-to-find wiki age. (Except for some stuff related to generating documentation and docbook, but whatever.)

2 3

A process for reporting security-sensitive issues
by Michael Smith 04 Sep '15

04 Sep '15

I feel there should be some process for reporting security-sensitive issues in GHC -- for example, #9562 and #10826 in Trac. Perhaps something like the SensitiveTicketsPlugin [3] could be used? [1] https://ghc.haskell.org/trac/ghc/ticket/9562 [2] https://ghc.haskell.org/trac/ghc/ticket/10826 [3] https://trac-hacks.org/wiki/SensitiveTicketsPlugin

3 2

Foreign calls and periodic alarm signals
by Phil Ruffwind 04 Sep '15

04 Sep '15

TL;DR: Does 'foreign import safe' silence the periodic alarm signals? I received a report on this rather strange bug in 'directory': https://github.com/haskell/directory/issues/35#issuecomment-136890912 I've concluded based on the dtruss log that it's caused by the timer signal that the GHC runtime emits. Somewhere inside the guts of 'realpath' on Mac OS X, there is a function that does the moral equivalent of: while (statfs64(…) && errno == EINTR); On a slow filesystem like SSHFS, this can cause a permanent hang from the barrage of signals. The reporter found that using 'foreign import safe' mitigates the issue. What I'm curious mainly is that: is something that the GHC runtime guarantees -- is using 'foreign import safe' assured to turn off the periodic signals for that thread? I tried reading this article [1], which seems to be the only documentation I could find about this, and it didn't really go into much depth about them. (I also couldn't find any info about how frequently they occur, on which threads they occur, or which specific signal it uses.) I'm also concerned whether there are other foreign functions out in the wild that could suffer the same bug, but remain hidden because they normally complete before the next alarm signal. [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals

2 2

Re: [Diffusion] [Committed] rGHCbe0ce8718ea4: Fix for crash in setnumcapabilities001
by Thomas Miedema 03 Sep '15

03 Sep '15

Simon, for what it's worth, I sporadically (< once per month) see this test timing out on Phabricator. Latest occurence: https://phabricator.haskell.org/harbormaster/build/5904/?l=0 Thomas On Fri, Jun 26, 2015 at 10:32 AM, simonmar (Simon Marlow) < noreply(a)phabricator.haskell.org> wrote: > simonmar committed rGHCbe0ce8718ea4: Fix for crash in > setnumcapabilities001 (authored by simonmar). > > Fix for crash in setnumcapabilities001 > > getNewNursery() was unconditionally incrementing next_nursery, which > is normally fine but it broke an assumption in > storageAddCapabilities(). This manifested as an occasional crash in > the setnumcapabilities001 test. >

1 0

Fwd: RE: D1182: Implement improved error messages for ambiguous type variables (#10733)
by Edward Z. Yang 03 Sep '15

03 Sep '15

It's certainly true that hsig is in flux, but it doesn't seem like injective type families should have broken this test. I'll take a look. Edward Excerpts from Simon Peyton Jones's message of 2015-09-03 09:08:23 -0700: > Edward > > | Jan's injective type families commit is causing tcfail220 to fail, but > | that's unrelated to this ticket. > > This is true. I told Jan to commit anyway because tcfail220 is a "hsig" test, and > a) I know that hsigs are in flux (although I am not clear about how) > b) I don't understand them enough to fix. > > So I hope it's ok to have broken this. Jan and I can certainly help when you want to fix it. > > Meanwhile would you mark it as expect-broken. (Although I am not sure that it's worth opening a fresh ticket for it.) > > thanks > > Simon > > | -----Original Message----- > | From: noreply(a)phabricator.haskell.org > | [mailto:noreply@phabricator.haskell.org] > | Sent: 03 September 2015 07:11 > | To: Simon Peyton Jones > | Subject: [Differential] [Commented On] D1182: Implement improved error > | messages for ambiguous type variables (#10733) > | > | KaneTW added a comment. > | > | Jan's injective type families commit is causing tcfail220 to fail, but > | that's unrelated to this ticket. > | > | > | REPOSITORY > | rGHC Glasgow Haskell Compiler > | > | REVISION DETAIL > | https://phabricator.haskell.org/D1182 > | > | EMAIL PREFERENCES > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: KaneTW, simonpj, bgamari, austin > | Cc: goldfire, simonpj, thomie --- End forwarded message ---

2 2

addTopDecls restrictions
by Richard Eisenberg 03 Sep '15

03 Sep '15

Hi Geoff, The TH addTopDecls function is restricted to only a few kinds of declarations (functions, mostly). This set has been expanded in #10486 (https://ghc.haskell.org/trac/ghc/ticket/10486) Do you remember why the set of allowed declarations is restricted? It looks to me like any declaration would be OK. Thanks! Richard

1 0