- ghc-devs - Haskell.org

Aargh! Windows build is broken AGAIN
by Simon Peyton Jones 15 Oct '16

15 Oct '16

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! Simon

5 6

Updated Phabricator Home Page
by Matthew Pickering 14 Oct '16

14 Oct '16

Hi all, I have updated the homepage for our phabricator installation. I moved some things around, deleted some unused panels and updated the landing text. If anyone has any other gripes with the installation please message me and I will see if I can fix them! If you liked the old version better, you can install your own dashboard by going to the dashboard interface - https://phabricator.haskell.org/dashboard/ - and installing dashboard 2. You can also create your own personal dashboard this way if you want to display custom queries for example. Matt

1 0

qualified module export
by Karl Cronburg 13 Oct '16

13 Oct '16

Hello, I'm attempting to add support for export of qualified modules (feature request #8043), and any guidance would be greatly appreciated. Namely I'm very familiar with languages / grammars / happy and was easily able to add an appropriate production alternative to Parser.y to construct a new AST node when 'qualified module' is seen in the export list, i.e.: | 'module' modid {% amsu (sLL $1 $> (IEModuleContents $2)) [mj AnnModule $1] } | 'qualified' 'module' qconid --maybeas {% amsu (sLL $2 $> (IEModuleQualified $3)) [mj AnnQualified $1] } But now I'm lost in the compiler internals. Where should I be looking / focusing on? In particular: - Where do exported identifiers get added to the list of "[LIE Name]" in ExportAccum (in TcRnExports.hs)? Thanks, -Karl Cronburg-

3 2

failing
by Simon Peyton Jones 12 Oct '16

12 Oct '16

Ben: all builds are failing https://phabricator.haskell.org/harbormaster/ What’s up? I see a perf failure on T1969. Does not happen for me; and is only in residency, so just bump it? Simon

2 3

Register Allocator Tests
by Thomas Jakway 12 Oct '16

12 Oct '16

Can anyone point me to the register allocator tests (especially for the graph register allocator)? Can't seem to find them and grepping doesn't turn up much (pretty much just testsuite/tests/codeGen/should_run/cgrun028.h).

3 4

Re: Reading floating point
by David Feuer 11 Oct '16

11 Oct '16

I fully expect this to be somewhat tricky, yes. But some aspects of the current implementation strike me as pretty clearly non-optimal. What I meant about going through Rational is that given "625e-5", say, it calculates 625%100000, producing a fraction in lowest terms, before calling fromRational, which itself invokes fromRat'', a division function optimized for a special case that doesn't seem too relevant in this context. I could be mistaken, but I imagine even reducing to lowest terms is useless here. The separate treatment of the digits preceding and following the decimal point doesn't do anything obviously useful either. If we (effectively) normalize in decimal to an integral mantissa, for example, then we can convert the whole mantissa to an Integer at once; this will balance the merge tree better than converting the two pieces separately and combining. On Oct 10, 2016 6:00 AM, "Yitzchak Gale" <gale(a)sefer.org> wrote: The way I understood it, it's because the type of "floating point" literals is Fractional a => a so the literal parser has no choice but to go via Rational. Once you have that, you use the same parser for those Read instances to ensure that the result is identical to what you would get if you parse it as a literal in every case. You could replace the Read parsers for Float and Double with much more efficient ones. But you would need to provide some other guarantee of consistency with literals. That would be more difficult to achieve than one might think - floating point is deceivingly tricky. There are already several good parsers in the libraries, but I believe all of them can provide different results than literals in some cases. YItz On Sat, Oct 8, 2016 at 10:27 PM, David Feuer <david.feuer(a)gmail.com> wrote: > The current Read instances for Float and Double look pretty iffy from an > efficiency standpoint. Going through Rational is exceedingly weird: we have > absolutely nothing to gain by dividing out the GCD, as far as I can tell. > Then, in doing so, we read the digits of the integral part to form an > Integer. This looks like a detour, and particularly bad when it has many > digits. Wouldn't it be better to normalize the decimal representation first > in some fashion (e.g., to 0.xxxxxxexxx) and go from there? Probably less > importantly, is there some way to avoid converting the mantissa to an > Integer at all? The low digits may not end up making any difference > whatsoever. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

3 8

when building latest GHC on Mac with Xcode 8: Symbol not found: _clock_gettime
by John Leo 11 Oct '16

11 Oct '16

Hi everyone, I'm trying to compile ghc from the latest source and am hitting an error "Symbol not found: _clock_gettime". I'm on Mac El Capitan and recently installed Xcode 8 which I'm sure is what caused the problem. Using Google I found some relevant pages including this one https://mail.haskell.org/pipermail/ghc-devs/2016-July/012511.html but I've been unable to figure out what I can do to fix the problem. Any help would be appreciated. The tail end of my compilation output is below. Thanks in advance. John cat ghc/ghc.wrapper >> inplace/bin/ghc-stage2 chmod +x inplace/bin/ghc-stage2 "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -Wall -hide-all-packages -i -iutils/ghctags/. -iutils/ghctags/dist-install/build -Iutils/ghctags/dist-install/build -iutils/ghctags/dist-install/build/ghctags/autogen -Iutils/ghctags/dist-install/build/ghctags/autogen -optP-include -optPutils/ghctags/dist-install/build/ghctags/autogen/cabal_macros.h -package-id Cabal-1.25.0.0 -package-id base-4.9.0.0 -package-id containers-0.5.7.1 -package-id ghc-8.1 -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir utils/ghctags/dist-install/build -hidir utils/ghctags/dist-install/build -stubdir utils/ghctags/dist-install/build -c utils/ghctags/./Main.hs -o utils/ghctags/dist-install/build/Main.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -Wall -hide-all-packages -i -iutils/check-api-annotations/. -iutils/check-api-annotations/dist-install/build -Iutils/check-api-annotations/dist-install/build -iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -Iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -optP-include -optPutils/check-api-annotations/dist-install/build/check-api-annotations/autogen/cabal_macros.h -package-id Cabal-1.25.0.0 -package-id base-4.9.0.0 -package-id containers-0.5.7.1 -package-id directory-1.2.6.2 -package-id ghc-8.1 -Wall -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir utils/check-api-annotations/dist-install/build -hidir utils/check-api-annotations/dist-install/build -stubdir utils/check-api-annotations/dist-install/build -c utils/check-api-annotations/./Main.hs -o utils/check-api-annotations/dist-install/build/Main.dyn_o dyld: lazy symbol binding failed: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib dyld: lazy symbol binding failed: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib make[1]: *** [utils/ghctags/dist-install/build/Main.dyn_o] Trace/BPT trap: 5 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/check-api-annotations/dist-install/build/Main.dyn_o] Trace/BPT trap: 5 make: *** [all] Error 2 i

2 2

RE: [Diffusion] [Build Failed] rGHCa6111b8cc14a: More tests for Trac #12522
by Simon Peyton Jones 10 Oct '16

10 Oct '16

This says “stat not good enough” for “max_bytes_used” on T1969. I pushed a “T1969 is ok” patch recently, because it IS ok on my (64-bit Linux) machine. If it’s not ok for our CI infrastructure, by all means un-push it or something. Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 10 October 2016 15:07 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHCa6111b8cc14a: More tests for Trac #12522 Harbormaster failed to build B11303: rGHCa6111b8cc14a: More tests for Trac #12522! BRANCHES master USERS simonpj (Author) O7 (Auditor) COMMIT https://phabricator.haskell.org/rGHCa6111b8cc14a EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

1 0

Reading floating point
by David Feuer 10 Oct '16

10 Oct '16

The current Read instances for Float and Double look pretty iffy from an efficiency standpoint. Going through Rational is exceedingly weird: we have absolutely nothing to gain by dividing out the GCD, as far as I can tell. Then, in doing so, we read the digits of the integral part to form an Integer. This looks like a detour, and particularly bad when it has many digits. Wouldn't it be better to normalize the decimal representation first in some fashion (e.g., to 0.xxxxxxexxx) and go from there? Probably less importantly, is there some way to avoid converting the mantissa to an Integer at all? The low digits may not end up making any difference whatsoever.

2 1

Allow top-level shadowing for imported names?
by Herbert Valerio Riedel 10 Oct '16

10 Oct '16

Hi *, I seem to recall this was already suggested in the past, but I can't seem to find it in the archives. For simplicity I'll restate the idea: foo :: Int -> Int -> (Int,Int) foo x y = (bar x, bar y) where bar x = x+x results merely in a name-shadowing warning (for -Wall): foo.hs:4:9: warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding bound at foo.hs:2:5 However, import Data.Monoid (<>) :: String -> String -> String (<>) = (++) main :: IO () main = putStrLn ("Hi" <> "There") doesn't allow to shadow (<>), but rather complains about ambiguity: bar.hs:7:23: error: Ambiguous occurrence ‘<>’ It could refer to either ‘Data.Monoid.<>’, imported from ‘Data.Monoid’ at bar.hs:1:1-18 or ‘Main.<>’, defined at bar.hs:4:1 This is of course in line with the Haskell Report, which says in https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-101000… | The entities exported by a module may be brought into scope in another | module with an import declaration at the beginning of the module. The | import declaration names the module to be imported and optionally | specifies the entities to be imported. A single module may be imported | by more than one import declaration. Imported names serve as top level | declarations: they scope over the entire body of the module but may be | shadowed by *local non-top-level bindings.* However, why don't we allow this to be relaxed via a new language extensions, to allow top-level bindings to shadow imported names (and of course emit a warning)? Unless I'm missing something, this would help to keep existing and working code compiling if new versions of libraries start exporting new symbols (which happen to clash with local top-level defs), rather than resulting in a fatal name-clash; and have no major downsides. If this sounds like a good idea, I'll happily promote this into a proper proposal over at https://github.com/ghc-proposals/ghc-proposals; I mostly wanted to get early feedback here (and possibly find out if and where this was proposed before), before investing more time turning this into a fully fledged GHC proposal. Cheers, HVR

15 19