- ghc-devs - Haskell.org

Stability of Uniques
by Edsko de Vries 29 Mar '13

29 Mar '13

Hi all, Consider the very simple test module Test2 where f = True When walking the AST after renaming I see that f has unique 1912603236 and True has unique 905969694. However, when walking the typechecked AST f seems to have unique 1627390565 instead. Should I expect that the unique associated with identifiers changes between renaming and typechecking? Or is there something else that I'm missing? Thanks! Edsko

2 4

Re: [commit: ghc] master: Track subrepos Cabal (cc097a4)
by Ian Lynagh 27 Mar '13

27 Mar '13

Hi Gabor, On Wed, Mar 20, 2013 at 02:38:27PM -0700, Gabor Greif wrote: > > commit cc097a43c851891c7a1535d2082c7e392230123d > Author: Gabor Greif <ggreif(a)gmail.com> > Date: Wed Mar 20 22:37:43 2013 +0100 > > Track subrepos Cabal If I'm understanding right, this adds a GHC-only patch to fix a couple of typos. Thanks you for your many typo fixes, but in the case of submodules this sort of patch should be sent upstream instead; that way less effort is needed overall, and there is no chance that the patches will be lost when we resync with upstream. We only make GHC-only patches when they are necessary to keep the build working. Thanks Ian

2 3

adding -ticky to, say, WAY_debug_HC_OPTS?
by Nicolas Frisby 27 Mar '13

27 Mar '13

(I admit that I remain intimidated by the build system.) I'm renabling some ticky counter bumps from within the RTS. The most direct path I see to this involves adding -ticky to makefile variables such as WAY_debug_HC_OPTS. (See the APPENDIX for why I need that.) It seems that the debug way is only used in the build system for building the RTS. Is that right? If so, will a flag added to the debug HC_OPTS vars in ways.mk only be used when compiling from .cmm sources? If so, my -ticky flag won't be putting ticky counters into any .o file where I'm not expecting them, right? So: 1) Is it a bad idea to add -ticky to the non-threaded and non-profiling WAY_debug*_HC_OPTS variables in ways.mk? 2) Alternative designs? A few come to mind, but they're more invasive/fragile. Thank you for your time. APPENDIX For example: * The (generated) definition of stg_ap_*_info uses BUILD_PAP * The definition of BUILD_PAP uses TICK_ALLOC_PAP * TICK_ALLOC_PAP is elaborated by CmmParse.y using StgCmmTicky.tickyAllocPAP * tickyAllocPAP emits no code unless Opt_Ticky is present. * -ticky is not currently in the relevant command lines

2 1

Could not find 'Prelude'
by Richard Eisenberg 27 Mar '13

27 Mar '13

On HEAD, commit b9d53..., a freshly built ghc-stage2 can't find its Prelude: > rae:22:06:54 ~/temp> ~/Documents/ghc-baseline/inplace/bin/ghc-stage2 Scratch.hs > > Scratch.hs:1:1: > Could not find module ‛Prelude’ > There are files missing in the ‛base’ package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > I'm building on Mac OS 10.7.5, and my build.mk is set to 'quick'. Any ideas? Thanks, Richard

2 3

An idea for improving workflow
by Jan Stolarek 26 Mar '13

26 Mar '13

I've been reading the ghc-devs list for quite some time now and I noticed that it often happens that one of the developers pushes the changes to the ghc.git repo but forgets to push the corresponding changes to the testsuite, which results in people trying to figure out why their validation fails. I was thinking if this problem could be eliminated. Perhaps it would make sense to add a server-side hook to the ghc.git repo that would display a message reminding to push the changes to the testsuite? That's definitely not an ultimate solution to the problem, but I think it could reduce the number of such situations. I played a bit with server-side hooks in git to see how that looks. The message is interspersed with other output from git, but I think we can make it visible enough. The message can even be displayed in color, though I am not sure how portable is this accross different terminals. Janek

2 4

Compiling Prelude.hs or complete base to external core
by Carlos Lopez Camey 26 Mar '13

26 Mar '13

Hi, I have an interpreter for external core and I would like to read the definitions in base:Prelude. After jumping over some obstacles [0], I find myself here: > ghc --make -fext-core -I./include -cpp Prelude.hs GHC/Num.lhs:65:27: Could not deduce (base:GHC.Num.Num a) arising from the literal `0' from the context (Num a) bound by the class declaration for `Num' at GHC/Num.lhs:(42,1)-(65,31) Possible fix: add (base:GHC.Num.Num a) to the context of the class declaration for `Num' In the first argument of `(-)', namely `0' In the expression: 0 - x In an equation for `negate': negate x = 0 - x If I jump over this one with some nonsense fix (e.g. negate = id) then I get GHC/Exception.lhs:47:14: Cannot derive well-kinded instance of form `Typeable * (SomeException ...)' Class `Typeable' expects an argument of kind `k' In the data declaration for `SomeException' GHC/Exception.lhs:169:24: Cannot derive well-kinded instance of form `Typeable * (ErrorCall ...)' Class `Typeable' expects an argument of kind `k' In the newtype declaration for `ErrorCall' GHC/Exception.lhs:186:22: Cannot derive well-kinded instance of form `Typeable * (ArithException ...)' Class `Typeable' expects an argument of kind `k' In the data declaration for `ArithException' Do you have any tips that help me? I am using the HEAD version of base and GHC 7.6.2. I also tried base-4.6.0.0 but the file HsFFI.h is looked upon and is not found or is not generated by ./configure (ieee-flpt.h: is a similar case, although I could find this one on the web [1]). [0] Manually compiled GHC/Event/{Poll,Clock,EPoll} with hsc2hs [1] http://darcs.haskell.org/packages/base/include/ieee-flpt.h Thanks

2 1

Fwd: [Haddock] error: utils/haddock_dist_PROGNAME is not set
by Rob Stewart 25 Mar '13

25 Mar '13

Hi Ian, That may well be true. However, I ran multiple ./sync-all commands, due to the following error that I am seeing with the parallel library: $ ./sync-all -r http://darcs.haskell.org --extra get -b ghc-7.6 ... Cloning into 'libraries/process'... == libraries/process: running git config --local core.ignorecase true == running git clone http://darcs.haskell.org/packages/template-haskell.git libraries/template-haskell -b ghc-7.6 Cloning into 'libraries/template-haskell'... == libraries/template-haskell: running git config --local core.ignorecase true == running git clone http://darcs.haskell.org/packages/unix.git libraries/unix -b ghc-7.6 Cloning into 'libraries/unix'... == libraries/unix: running git config --local core.ignorecase true == running git clone http://darcs.haskell.org/packages/parallel.git libraries/parallel -b ghc-7.6 Cloning into 'libraries/parallel'... fatal: Remote branch ghc-7.6 not found in upstream origin Unexpected end of command stream git failed: 32768 at ./sync-all line 193. -- Rob On 24 March 2013 19:03, Ian Lynagh <ian(a)well-typed.com> wrote: > On Sun, Mar 24, 2013 at 07:50:34PM +0100, David Waern wrote: >> Not sure what's wrong here. Maybe someone on ghc-devs@ knows. >> >> 2013/3/24 Rob Stewart <robstewart57(a)gmail.com> >> >> > I am not able to build ghc 7.6 from source, and come across an error >> > in utils/haddock/ghc.mk >> > >> > utils/haddock/ghc.mk:28: *** utils/haddock_dist_PROGNAME is not set. > > I suspect that either your haddock repository is out-of-date, or that > some of your repositories are on the 7.6 branch and some are on master. > > > Thanks > Ian >

1 0

Re: [Haddock] error: utils/haddock_dist_PROGNAME is not set
by David Waern 24 Mar '13

24 Mar '13

Not sure what's wrong here. Maybe someone on ghc-devs@ knows. David 2013/3/24 Rob Stewart <robstewart57(a)gmail.com> > Hi, > > I am not able to build ghc 7.6 from source, and come across an error > in utils/haddock/ghc.mk > > $ cd ghc > $ ./sync-all -r http://darcs.haskell.org --extra get -b ghc-7.6 > $ ./sync-all -r http://darcs.haskell.org --extra get # get > libraries/parallel and libraries/xhtml > $ perl boot > $ ./configure --prefix=/home/foo/bar/ > $ make > + test -f mk/config.mk.old > + cp -p mk/config.mk mk/config.mk.old > touch -r mk/config.mk.old mk/config.mk > + test -f mk/project.mk.old > + cp -p mk/project.mk mk/project.mk.old > touch -r mk/project.mk.old mk/project.mk > + test -f compiler/ghc.cabal.old > + cp -p compiler/ghc.cabal compiler/ghc.cabal.old > touch -r compiler/ghc.cabal.old compiler/ghc.cabal > ===--- building phase 0 > make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds > libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No > such file or directory > libraries/Cabal/Cabal/ghc.mk:3: > libraries/Cabal/Cabal/dist-boot/package-data.mk: No such file or > directory > libraries/bin-package-db/ghc.mk:3: > libraries/bin-package-db/dist-boot/package-data.mk: No such file or > directory > libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: > No such file or directory > libraries/transformers/ghc.mk:3: > libraries/transformers/dist-boot/package-data.mk: No such file or > directory > libraries/terminfo/ghc.mk:3: > libraries/terminfo/dist-boot/package-data.mk: No such file or > directory > utils/haddock/ghc.mk:28: *** utils/haddock_dist_PROGNAME is not set. > Stop. > > -- > Rob > > _______________________________________________ > Haddock mailing list > Haddock(a)projects.haskell.org > http://projects.haskell.org/cgi-bin/mailman/listinfo/haddock >

2 1

I/O manager: relying solely upon kqueue is not a safe way to go
by PHO 24 Mar '13

24 Mar '13

I found the HEAD stopped working on MacOS X 10.5.8 since the parallel I/O manager got merged to HEAD. Stage-2 compiler successfully builds (including Language.Haskell.TH.Syntax contrary to the report by Kazu Yamamoto) but the resulting binary is very unstable especially for ghci: % inplace/bin/ghc-stage2 --interactive GHCi, version 7.7.20130313: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> <stdin>: hGetChar: failed (Operation not supported) So I took a dtruss log and found it was kevent(2) that returned ENOTSUP. GHC.Event.KQueue was just registering the stdin for EVFILT_READ, whose type was of course tty, and then kevent(2) said "tty is not supported". Didn't the old I/O manager do the same thing? Why was it working then? After a hard investigation, I concluded that the old I/O manager was not really working. It just looked fine but in fact wasn't. Here's an explanation: If a fd to be registered is unsupported by kqueue, kevent(2) returns -1 iff no incoming event buffer is passed together. Otherwise it successfully returns with an incoming kevent whose "flags" is EV_ERROR and "data" contains an errno. The I/O manager has always been passing a non-empty event buffer until the commit e5f5cfcd, while it wasn't (and still isn't) checking if a received event in fact represents an error. That is, the KQueue backend asks the kernel to monitor the stdin's readability. The kernel then immediately delivers an event saying ENOTSUP. The KQueue backend thinks "Hey, the stdin is now readable!" so it invokes a callback associated with the fd. The thread which called "threadWaitRead" is now awakened and performs a supposedly non-blocking read on the fd, which in fact blocks but works anyway. However the situation has changed since the commit e5f5cfcd. The I/O manager now registers fds without passing an incoming event buffer, so kevent(2) no longer successfully delivers an error event instead it directly returns -1 with errno set to ENOTSUP, hence the "Operation not supported" exception. The Darwin's kqueue has started supporting tty since MacOS X 10.7 (Lion), but I heard it still doesn't support some important devices like /dev/random. FreeBSD's kqueue has some difficulties too. It's no doubt kqueue is a great mechanism for sockets, but IMHO it's not something to use for all kinds of file I/O. Should we then try kqueue(2) first and fallback to poll(2) if failed? Sadly no. Darwin's poll(2) is broken too, and select(2) is the only method reliable: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AND_DARWIN_BUGS I wrote a small program to test if a given stdin is supported by kqueue, poll and select: https://gist.github.com/phonohawk/5169980#file-kqueue-poll-select-cpp MacOS X 10.5.8 is hopelessly broken. We can't use anything other than select(2) for tty and other devices: https://gist.github.com/phonohawk/5169980#file-powerpc-apple-darwin9-8-0-txt FreeBSD 8.0 does support tty but not /dev/random. I don't know what about the latest FreeBSD 9.1: https://gist.github.com/phonohawk/5169980#file-i386-unknown-freebsd8-0-txt NetBSD 6.99.17 works perfectly here: https://gist.github.com/phonohawk/5169980#file-x86_64-unknown-netbsd6-99-17… Just for reference, Linux 2.6.16 surely doesn't have kqueue(2) but it supports poll(2)ing on devices: https://gist.github.com/phonohawk/5169980#file-x86_64-unknown-linux2-6-16-t… I accordingly suggest that we should have some means to run two independent I/O managers on BSD-like systems: KQueue for sockets, pipes and regular file reads, and Select for any other devices and regular file writes. Note also that no implementations of kqueue support monitoring writability of regular file writes, which also endangers the current use of kqueue-based I/O manager namely "threadWaitWrite". Any ideas? Thanks, PHO _______________________________________________________ - PHO - http://cielonegro.org/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72

7 23

Account on abbot
by Simon Peyton-Jones 24 Mar '13

24 Mar '13

Dear Paul Could you please give Nicolas Frisby an account on abbot, so he can commit to GHC? He'll send you his ssh public key. (Ian, is that all we need to let Nick commit?) Many thanks Simon

2 1