- ghc-devs - Haskell.org

Ready for Cabal release now?
by Johan Tibell 01 Mar '14

01 Mar '14

Hi, I know we're waiting until the last minute before the Cabal release that need to go into 7.8. Should I make that release now? -- Johan

3 7

Cabal-1.18.1.3 and cabal-install-1.18.0.3 RCs
by Johan Tibell 01 Mar '14

01 Mar '14

Hi all, I've uploaded release candidates for Cabal-1.18.1.3 (to be shipped with GHC 7.8) and cabal-install-1.18.0.3. You can install the RCs like so: cabal install http://johantibell.com/files/Cabal-1.18.1.3-rc.tar.gz http://johantibell.com/files/cabal-install-1.18.0.3-rc.tar.gz It's especially important that Cabal-1.18.1.3 gets some testing on OS X using GHC 7.8, as there's a change in how linking is done (see https://github.com/haskell/cabal/issues/1660) These RCs correspond to commit d310d87c2c445f52987169a2ce4da03c14070918 on the 1.18 branch in the cabal repo [1]. Note that both Cabal and cabal-install are released from the same repo. If you want to check which commits are new since last release run: git log Cabal-v1.18.1.2.. -- Cabal/ git log cabal-install-v1.18.0.2 -- cabal-install/ -- Johan 1. https://github.com/haskell/cabal

1 0

Re: first version of RC2 has problems with lack of dynamic libraries at least on the Mac
by George Colpitts 28 Feb '14

28 Feb '14

corrected subject line On Thu, Feb 27, 2014 at 7:47 PM, George Colpitts <george.colpitts(a)gmail.com>wrote: > Hi > > After installing the first version of RC2 I ran into the following problem > > cabal install vector > Resolving dependencies... > Configuring vector-0.10.9.1... > ... > [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( > Data/Vector/Fusion/Stream/Monadic.hs, > dist/build/Data/Vector/Fusion/Stream/Monadic.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL > for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib, 9): > image not found) > > There seems to be a general problem that the install did not produce any > dynamic libraries at least on the Mac: > > ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib: > HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a > > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib: > Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a > libHShashable-1.2.1.0_p.a > > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib: > HShscolour-1.20.3.o Language libHShscolour-1.20.3.a > libHShscolour-1.20.3_p.a > > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib: > Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a > Data include libHSprimitive-0.5.2.1_p.a > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib: > Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib: > Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a > > > /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib: > Data libHSunordered-containers-0.2.3.3.a > HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a >

3 9

Clean build ASSERT failure
by Simon Peyton Jones 28 Feb '14

28 Feb '14

I'm seeing this assertion failure when using the stage1 compiler (built with -DDEBUG) to compile the stage2 compiler. Is anyone else seeing this? Simon ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.9.20140227 for i386-unknown-mingw32): ASSERT failed! file compiler\basicTypes\Demand.lhs line 445 3 [U] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug compiler/ghc.mk:642: recipe for target 'compiler/stage2/build/ParserCore.o' failed

2 1

What does the DWARF information generated by your GHC branch look like?
by Johan Tibell 28 Feb '14

28 Feb '14

Hi! (I've CCed ghc-devs on this email, as I think the question is of general interest.) I enjoyed reading your paper [1] and I have some questions. * What does the generated DWARF information look like? For example, will you fill in the .debug_line section so that standard tools like "perf report" and gprof can be used on Haskell code? Code pointers would be appreciated. * Does your GHC allow DWARF information to be generated without actually using any of the RTS (e.g. eventlog) machinery? This would be very useful if you want to use "report record/report" only, in order to achieve minimal overhead when that matters. Another way to ask the same question, do you have a ghc -g flag that has no implication for the runtime settings? * Do you generate DW_TAG_subprogram sections in the .debug_info section so that other tools can figure out the name of Haskell functions? Cheers, Johan 1. "Causality of Optimized Haskell: What is burning our cycles?" http://eprints.whiterose.ac.uk/76448/

2 1

Re: What does the DWARF information generated by your GHC branch look like?
by Johan Tibell 28 Feb '14

28 Feb '14

On Thu, Feb 27, 2014 at 6:43 PM, Peter Wortmann <scpmw(a)leeds.ac.uk> wrote: > > Johan Tibell wrote: > > I enjoyed reading your paper [1] and I have some questions. > > Thanks! The DWARF patches are currently under review for Trac #3693. Any > feedback would be very appreciated: > https://github.com/scpmw/ghc/commits/profiling-import I haven't had time to look at it all. I added a comment on https://github.com/scpmw/ghc/commit/bbf6f35d8c341c8aadca1a48657084c007837b21 > > will you fill in the .debug_line section so that standard tools like > > "perf report" and gprof can be used on Haskell code? > > Yes, even though from a few quick tests the results of "perf report" > aren't too useful, as source code links are pretty coarse and jump > around a lot - especially for optimised Haskell code. There's the option > to instead annotate with source code links to a generated ".dump-simpl" > file, which might turn out to be more useful. > I think that in general we should be as "standard" (i.e. close to how e.g. GCC uses DWARF) as possible and put extra information in e.g. .debug_ghc. That way we maximize the chance that standard tools will do something sensible. > > Code pointers would be appreciated. > > Is this about how .debug_line information is generated? We take the same > approach as LLVM (and GCC, I think) and simply annotate the assembly > with suitable .file & .loc directives. That way we can leave all the > heavy lifting to the assembler. > > Current patch is here: > https://github.com/scpmw/ghc/commit/c5294576 Makes sense. Thanks. > > * Does your GHC allow DWARF information to be generated without > > actually using any of the RTS (e.g. eventlog) machinery? > > The RTS just serves as a DWARF interpreter for its own executable (+ > libraries) in this, so yes, it's fully independent. On the other hand, > having special code allows us to avoid a few subtleties about Haskell > code that are hard to communicate to standard debugging tools > (especially concerning stack tracing). > Sounds good. As long as it's possible to use this without the RTS/eventlog support I be happy. I have profiling needs (e.g. in unordered-containers) were changes in the <5% are interesting and any extra overhead will skew the results. > > Another way to ask the same question, do you have a ghc -g flag that > > has no implication for the runtime settings? > > Right now -g does not affect the RTS at all. We might want to change > that at some point though so we can get rid of the libdwarf dependency. > That sounds good (the don't affect the RTS part). I didn't understand the libdwarf part. > > * Do you generate DW_TAG_subprogram sections in the .debug_info > > section so that other tools can figure out the name of Haskell > > functions? > > Yes, we are setting the "name" attribute to a suitable Haskell name. > Sadly, at least GDB seems to ignore it and falls back to the symbol > name. I investigated this some time ago, and I think the reason was that > it doesn't recognize the Haskell language ID (which isn't standardized, > obviously). Simply pretending to be C(++) might fix this, but I would be > a bit scared of other side-effects. > Lets try to get our name standardized and pushed into GDB. It's hopefully as simple as sending an email to the GDB devs. Cheers, Johan

1 0

first version of RC2 has problems with lack of dynamic problems at least on the Mac
by George Colpitts 27 Feb '14

27 Feb '14

Hi After installing the first version of RC2 I ran into the following problem cabal install vector Resolving dependencies... Configuring vector-0.10.9.1... ... [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib, 9): image not found) There seems to be a general problem that the install did not produce any dynamic libraries at least on the Mac: ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib: HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib: Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a libHShashable-1.2.1.0_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib: HShscolour-1.20.3.o Language libHShscolour-1.20.3.a libHShscolour-1.20.3_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib: Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a Data include libHSprimitive-0.5.2.1_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib: Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib: Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib: Data libHSunordered-containers-0.2.3.3.a HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a

2 1

RC2 release imminent
by Austin Seipp 27 Feb '14

27 Feb '14

Hello all, Just as a quick update, the RC2 release will be soon. I plan on fixing #8736 and releasing it. #8696 will come shortly with the final release. I'll follow up when a source tarball is available, so Pali and Karel can build binaries. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

8 17

SPARC: why it's not registerised anymore?
by Karel Gardas 26 Feb '14

26 Feb '14

Folks, just out of curiosity I'm building latest GHC on SPARC/Solaris and I've noted that current GHCs (7.6 and HEAD) are building unregisterised by default. In the history I remember at least some GHC were registerised and GHC source code also (still) contains SPARC NCG so I'm curious what was the reason behind the switch? Any bug still waiting for a fix? Or just code rotted in a way it's not working any more? Thanks! Karel

2 3

would support for kind equalities enable the following example?
by Carter Schonwald 26 Feb '14

26 Feb '14

Hey all, I've a use case in my code where It looks like it might be an example of something that won't compile until we have type level GADTs I'm essentially writing a vector api that allows certain args to be mutable, pure or "dont care". (dont care = that they're treated as being immutable). I'm using GADTs to model this. (using GADTs rather than type classes partly because I want to make sure type inference works out nicely, and partly to see how far i can go while not adding any new type classes) data Eff :: * -> * where Pure :: Eff () Mut :: s -> Eff s data EVector :: * -> * -> * where PureVector :: S.Vector el -> EVector Pure el MutVector :: SM.MVector s el -> EVector (Mut s) el the above doesn't work because DataKinds only works at kind * currently, however i can defunctionalize it to the following (while making it a tad less pretty) and it then works data Eff = Pure | Mut data EVector :: Eff -> * -> * -> * where PureVector :: S.Vector el -> EVector Pure () el MutVector :: SM.MVector s el -> EVector Mut s el am i correct in thinking that the first example *should* be possible once we have fancier kind machinery (kind equalities and type level GADTs?)? I suspect I'll be hitting *A LOT* more examples like the above, and if theres any ways I can help push this along on the research or engineering side, I please tell me :) thanks! -Carter

2 4