February 2014 - ghc-devs

old-time.git/tests/time004.hs is DST-sensitive :-/
by Herbert Valerio Riedel 26 Oct '14

26 Oct '14

Hi *, if anyone wonders, why TEST=time004 suddenly fails: it's sensitive to DST (and depends on your system's TZ-config): http://git.haskell.org/packages/old-time.git/blob/HEAD:/tests/time004.hs For me, the comparison this unit-test checks now suddenly fails, because the DST-switch occurs on different days in 2012 and 2013 in my TZ, i.e. length "Sun Oct 27 10:56:42 CET 2013" /= length "Sat Oct 27 11:56:42 CEST 2012" Does anyone happen to know what the rationale behind this 'time004' unit test was? Cheers, hvr

1 1

Extending fold/build fusion
by Akio Takano 05 Sep '14

05 Sep '14

Hi, I have been thinking about how foldl' can be turned into a good consumer, and I came up with something that I thought would work. So I'd like to ask for opinions from the ghc devs: if this idea looks good, if it is a known bad idea, if there is a better way to do it, etc. The main idea is to have an extended version of foldr: -- | A mapping between @a@ and @b@. data Wrap a b = Wrap (a -> b) (b -> a) foldrW :: (forall e. Wrap (f e) (e -> b -> b)) -> (a -> b -> b) -> b -> [a] -> b foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0 where go = unwrap $ \list z' -> case list of [] -> z' x:xs -> f x $ wrap go xs z' This allows the user to apply an arbitrary "worker-wrapper" transformation to the loop. Using this, foldl' can be defined as newtype Simple b e = Simple { runSimple :: e -> b -> b } foldl' :: (b -> a -> b) -> b -> [a] -> b foldl' f initial xs = foldrW (Wrap wrap unwrap) g id xs initial where wrap (Simple s) e k a = k $ s e a unwrap u = Simple $ \e -> u e id g x next acc = next $! f acc x The wrap and unwrap functions here ensure that foldl' gets compiled into a loop that returns a value of 'b', rather than a function 'b -> b', effectively un-CPS-transforming the loop. I put preliminary code and some more explanation on Github: https://github.com/takano-akio/ww-fusion Thank you, Takano Akio

5 20

RE: OverloadedRecordFields
by Simon Peyton Jones 18 Apr '14

18 Apr '14

Adam I'm very happy to hear that... good stuff. I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. So I suggest we plan to merge after 7.8 is out. Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense Simon | -----Original Message----- | From: Adam Gundry [mailto:adam@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | > Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | > | > Simon | > | > | -----Original Message----- | > | From: Adam Gundry [mailto:adam@well-typed.com] | > | Sent: 17 January 2014 10:15 | > | To: Simon Peyton Jones | > | Subject: OverloadedRecordFields | > | | > | Hi Simon, | > | | > | I'm conscious that things have gone off the boil a little wrt | > | OverloadedRecordFields, partially as a consequence of the delayed | > | 7.8 release but also my lack of time for other projects since | > | starting work for Well-Typed. With that in mind, I'd like to propose | > | a plan to get back on track: | > | | > | 1. Revert to the three-parameter story, where we have | > | | > | t ~ FldTy r f => Has r f t | > | | > | rather than | > | | > | Has r f. | > | | > | The two-parameter version generates significantly worse error | > | messages, and there are some other unresolved problems, so I'm not | > | sure it is worth the minor simplification. | > | | > | 2. Roll back some of the refactoring that I've struggled to get | > | right (in particular, trying to make the generated FldTy/UpdTy | > | axioms implicitTyThings). We can always revisit this in the future | though. | > | | > | 3. Merge HEAD into my branch: I suspect this will be a bit painful | > | by now, but presumably with 7.8 imminent there won't be many major | > | changes coming for a while? | > | | > | 4. Review the proposed changes with you and fix any show-stopping | > | problems. | > | | > | 5. Merge into HEAD after 7.8 is released. | > | | > | Does this sound plausible? I'm happy to Skype if you like. | > | | > | Cheers, | > | | > | Adam | > | | > | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but | > | Neil Ghani has got me some funding to work with them both on units | > | of measure for Haskell. We are still sorting out the details, but I | > | hope it might be possible to work on some kind of plugin mechanism | > | for GHC's constraint solver, along the lines that Iavor has been | > | investigating, if that would be of interest? | > | | > | -- | > | Adam Gundry, Haskell Consultant | > | Well-Typed LLP, http://www.well-typed.com/ | > | | | -- | Adam Gundry, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/

4 4

Request: export runTcInteractive from TcRnDriver
by p.k.f.holzenspies＠utwente.nl 12 Mar '14

12 Mar '14

Dear GHC-devs, Is there a reason why, in HEAD, TcRnDriver does *not* export runTcInteractive? If not, can it please be added? (I considered sending a patch with this email, but it's so trivial a change that the check of the patch is more work than manually adding runTcInteractive to the export list.) I'm developing against the GHC API of 7.6.3 and it would have saved me hours of work to have precisely that function. Seeing it's in HEAD, but not being exported seems a shame ;) Regards, Philip

3 3

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

03 Mar '14

On Fri, Feb 28, 2014 at 3:15 PM, Peter Wortmann <scpmw(a)leeds.ac.uk> wrote: > Johan Tibell wrote:> Lets try to get our name standardized and pushed into > GDB. It's > > hopefully as simple as sending an email to the GDB devs. > > Strictly speaking standardization is the job of the DWARF format > committee, which seem to currently be in the process of specifying > DWARF5[1]. Not quite sure we have a strong enough case, but if we wanted > our own language ID these would probably be the right people to ask. > I just emailed the DWARF discussion mailing list to sort this out. -- Johan

5 10

Runtime error using LLVM bitcode execution
by Benzinger, Ralph 03 Mar '14

03 Mar '14

Hello, My apologies in advance if this mailing list is not the appropriate address for posting my problem with the GHC runtime, but it seemed like the best option on the GHC home page. I'm trying to execute standalone Haskell functions exported via FFI and compiled as LLVM bitcode. Unfortunately, all my efforts yield the following runtime error: lu003107:~/hs-bitcode> ./bce_so hsallinone.bc hs_init complete hs_add_root complete hsallinone: internal error: stg_ap_p_ret (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug 0 bce_so 0x0000000000d6b310 1 bce_so 0x0000000000d6b53b 2 bce_so 0x0000000000d6ba1c 3 libpthread.so.0 0x00007f7683298800 4 libc.so.6 0x00007f7682592b35 gsignal + 53 5 libc.so.6 0x00007f7682594111 abort + 385 6 libHSrts-ghc7.6.3.so 0x00007f7683f6ca21 rtsFatalInternalErrorFn + 177 7 libHSrts-ghc7.6.3.so 0x00007f7683f6cce1 barf + 145 8 libHSrts-ghc7.6.3.so 0x00007f7683f8a24a stg_ap_p_info + 130 Stack dump: 0. Program arguments: ./bce_so hsallinone.bc Aborted This is what I do: I have a function hfun.hs that exports a function foreign export ccall hfun :: CInt -> CInt and a wrapper cmain.c that calls this function: #include <HsFFI.h> #include "hfun_stub.h" extern void __stginit_HFun(void); #include <stdio.h> int main(int argc, char *argv[]) { hs_init(&argc, &argv); printf("hs_init complete\n"); hs_add_root(__stginit_HFun); printf("hs_add_root complete\n"); int i = hfun(42); printf("hfun(42) = %d\n", i); hs_exit(); return 0; } To generate a callable bitcode file I use these commands: $ ghc -S -keep-llvm-files -keep-tmp-files hfun.hs $ llvm-as hfun.ll $ cp /tmp/... hfun_stub.c $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include hfun_stub.c $ clang -c -emit-llvm -I /opt/ghc/lib/ghc-7.6.3/include cmain.c $ llvm-link cmain.bc hfun_stub.bc hfun.bc -o hsallinone.bc My main program "bce_so" loads the linked bitcode and feeds it to the LLVM execution engine. All required Haskell runtime libraries are linked dynamically against bce_so. Could you kindly provide some insight on whether this runtime error is due to a bug with GHC (unlikely) or rather some negligence in my setup? Or does the issue highlight some principal limitation in my (admittedly somewhat naive) approach of using LLVM -- threading support, maybe? Note that compiling hfun.hs/cmain.c into a .so and executing everything natively using ldload() works flawlessly. Regards Ralph -- Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

4 7

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

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