- Glasgow-haskell-users

GHC 7.2.2 Distribution.Simple.Program.Ar
by Joe Buehler 18 May '12

18 May '12

I built GHC 7.2.2 on a LINUX box running RHEL 3. When compiling a package using this GHC it is trying to invoke ar thus: execve("/usr/bin/ar", ["/usr/bin/ar", "-r", "-c", "dist/build/libHSregex-base-0.93."..., "dist/build/Text/Regex/Base.o", "dist/build/Text/Regex/Base/Regex"..., "dist/build/Text/Regex/Base/Conte"..., "dist/build/Text/Regex/Base/Impl."...], [/* 45 vars */]) = 0 My version of ar does not like being invoked as "/usr/bin/ar -r -c lib.a file file file...", it complains that the .a file is missing. I believe it should be "/usr/bin/ar rc lib.a file file file...". This appears to originate in Distribution.Simple.Program.Ar. Can someone tell me what is going on here? Joe Buehler

2 1

How to force recompilation of preprocessed files (-F -pgmF ..)
by Simon Hengel 17 May '12

17 May '12

Hi, I'm experimenting with a preprocessor to automatically generate test drivers[1]. The result depends on the existence of other files on the disk. When files are added or removed, the test driver has to be regenerated. Ideally ghc would just always recompile that single file (akin to make's .PHONY), and it should work with ghci's :reload and with cabal. I tried to touch the file within the preprocessor, but this does not work. It seems, that GHC checks the modification time only after preprocessing. Any ideas how to tackle this? Cheers, Simon [1] https://github.com/sol/hspec-discover

2 2

Heads up: importing the Cabal issue tracker to github next week
by Bryan O'Sullivan 17 May '12

17 May '12

I am planning on doing this early next week, probably in two phases. As part of the import process, github will generate a *lot* of notification emails. I'm afraid there is nothing I can do to stem the tide, as github does not provide a mechanism to suppress these. If you have a github account, please brace yourself.

1 0

[ANN] Accelerate version 0.12: GPU computing with Haskell
by Manuel M T Chakravarty 14 May '12

14 May '12

We just released version 0.12 of Data.Array.Accelerate, the GPGPU[1] library for Haskell: http://justtesting.org/gpu-accelerated-array-computations-in-haskell This is a beta release. The library is not perfect, but it is definitely usable, and we are looking for early adopters. Manuel [1] Currently only NVIDIA GPUs are supported via NVIDIA's CUDA framework.

1 0

7.4.2 release plan update
by Ian Lynagh 13 May '12

13 May '12

Hi all, A quick 7.4.2 release plan update: We've been having trouble with our nightly builds, so we haven't managed to put out a release candidate yet. As soon as we have builds ready, we'll put the RC out, and all being well the release will follow one or two weeks later. Thanks Ian, on behalf of the GHC team

1 1

Win64 support
by Bulat Ziganshin 09 May '12

09 May '12

Hello glasgow-haskell-users, the one thing that users of my program asked most is the Win64 support: http://code.google.com/p/freearc/issues/list . we have waited for a several years, but it's still not in GHC, so i want to know at least: why it's not going forward? can we have unregisterized build at least? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

Explicit calls to the garbage collector.
by Jurriaan Hage 08 May '12

08 May '12

LS. I have a very memory intensive application. It seems that the timing of my application depend very much on the precise setting of -H...M in the runtime system (-H2000M seems to work best, computation time becomes a third of what I get when I pass no -H option). I conjecture that this good behaviour is the result of gc happening at the right time. So I wondered: if I can one when is the right time, is it possible then to trigger GC explicitly from within the Haskell code? best, Jur

5 5

Weird behavior of the NonTermination exception
by Bas van Dijk 04 May '12

04 May '12

Hello, Before I turn the following into a ticket I want to ask if I miss something obvious: When I run the following program: ------------------------------------------------- import Prelude hiding (catch) import Control.Exception import Control.Concurrent main :: IO () main = do mv <- newEmptyMVar _ <- forkIO $ do catch action (\e -> putStrLn $ "I solved the Halting Problem: " ++ show (e :: SomeException)) putStrLn "putting MVar..." putMVar mv () putStrLn "putted MVar" takeMVar mv action :: IO () action = let x = x in x ------------------------------------------------- I get the output: $ ghc --make Loop.hs -o loop -O2 -fforce-recomp && ./loop [1 of 1] Compiling Main ( Loop.hs, Loop.o ) Linking loop ... loop: thread blocked indefinitely in an MVar operation I solved the Halting Problem: <<loop>> putting MVar... putted MVar As can be seen, the putMVar is executed successfully. So why do I get the message: "thread blocked indefinitely in an MVar operation"? Note that if I change the action to a normal error the message disappears. I discovered this bug when hunting for another one. I have a Haskell web-server where one of the request handlers contained a loop. All exceptions thrown by handlers are caught and logged. When executing the looping handler I noticed ~0% CPU usage so I assumed that the handler wasn't actually looping because a NonTermination exception was thrown. However for some reason the NonTermination exception was not caught and logged. I haven't yet isolated this bug into a small test-case but when trying that I discovered the above. Regards, Bas

3 5

trouble building ghc-7.4 on Fedora 18 (devel) ARM
by Jens Petersen 04 May '12

04 May '12

Hi, I have been struggling to build ghc74 on ARM (ideally with llvm3) on Fedora 18 (the current development tree). After applying 4 recent ARM patches from Debian the ghc-7.4.1 build gets to: : "inplace/bin/ghc-stage1" -H32m -O -package-name base-4.5.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.4.0.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O2 -no-user-package-conf -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/dist-install/build/GHC/Event/Clock.hs -o libraries/base/dist-install/build/GHC/Event/Clock.o [parallel build line removed] /usr/bin/ld: error: /tmp/ghc5703_0/ghc5703_0.o uses VFP register arguments, libraries/base/dist-install/build/GHC/Event/Clock.o does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc5703_0/ghc5703_0.o collect2: error: ld returned 1 exit status make[1]: *** [libraries/base/dist-install/build/GHC/Event/Clock.o] Error 1 (full build log at: http://arm.koji.fedoraproject.org/koji/getfile?taskID=723311&name=build.log and more details at http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=723311) I gather that it builds on Debian so I am not quite why it is failing on Fedora. To see if ghc-7.4.2pre is any better I tried building ghc-7.4.1.20120416 too (without any ARM patches), which gets a lot further, to using llvm: "inplace/bin/ghc-stage1" -H32m -O -package-name array-0.4.0.0 -hide-all-packages -i -ilibraries/array/. -ilibraries/array/dist-install/build -ilibraries/array/dist-install/build/autogen -Ilibraries/array/dist-install/build -Ilibraries/array/dist-install/build/autogen -Ilibraries/array/include -optP-include -optPlibraries/array/dist-install/build/autogen/cabal_macros.h -package base-4.5.1.0 -XHaskell98 -XMultiParamTypeClasses -XFlexibleContexts -XFlexibleInstances -XTypeSynonymInstances -XDeriveDataTypeable -XStandaloneDeriving -XRank2Types -XMagicHash -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XCPP -O2 -no-user-package-conf -rtsopts -odir libraries/array/dist-install/build -hidir libraries/array/dist-install/build -stubdir libraries/array/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/array/./Data/Array/IO/Internals.hs -o libraries/array/dist-install/build/Data/Array/IO/Internals.o libraries/array/Data/Array/IO/Internals.hs:2:16: Warning: -#include and INCLUDE pragmas are deprecated: They no longer have any effect Instruction referencing instruction not embedded in a basic block! %ln2ulc = getelementptr inbounds i32* %Sp_Arg, i32 3 %ln2uld = ptrtoint i32* %ln2ulc to i32 Instruction does not dominate all uses! %ln2ulc = getelementptr inbounds i32* %Sp_Arg, i32 3 tail call cc10 void @stg_ap_ppp_fast(i32* %Base_Arg, i32* %ln2ulc, i32* %ln2uk8, i32 %ln2uky, i32 ptrtoint (%templatezmhaskell_LanguageziHaskellziTHziSyntax_zdfDataFunDepzuzddData_closure_struct* @templatezmhaskell_LanguageziHaskellziTHziSyntax_zdfDataFunDepzuzddData_closure to i32), i32 %ln2ul2, i32 %ln2ul6, i32 %SpLim_Arg) nounwind Broken module found, compilation aborted! 0 libLLVM-3.0.so 0x4058f348 1 libLLVM-3.0.so 0x4058f7b4 2 libc.so.6 0x4150a0b0 __default_sa_restorer_v2 + 0 3 libc.so.6 0x41508c7c gsignal + 64 4 libc.so.6 0x4150a2bc abort + 432 5 libLLVM-3.0.so 0x406f88e0 6 libLLVM-3.0.so 0x406e7678 llvm::FPPassManager::runOnFunction(llvm::Function&) + 440 7 libLLVM-3.0.so 0x406e7760 llvm::FPPassManager::runOnModule(llvm::Module&) + 48 8 libLLVM-3.0.so 0x406e733c llvm::MPPassManager::runOnModule(llvm::Module&) + 396 9 libLLVM-3.0.so 0x406e7484 llvm::PassManagerImpl::run(llvm::Module&) + 108 10 opt 0x00014528 main + 2268 11 libc.so.6 0x414f2dd0 __libc_start_main + 272 Stack dump: 0. Program arguments: opt /tmp/ghc22413_0/ghc22413_0.ll -o /tmp/ghc22413_0/ghc22413_0.bc -O2 1. Running pass 'Function Pass Manager' on module '/tmp/ghc22413_0/ghc22413_0.ll'. 2. Running pass 'Module Verifier' on function '@seuH_info' make[1]: *** [libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.o] Error 1 (full log at http://arm.koji.fedoraproject.org/koji/getfile?taskID=746853&name=build.log, more details at http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=746853) I haven't tried HEAD yet though the results at http://darcs.haskell.org/ghcBuilder/builders/kgardas-linux-arm-head/index.h… are not too encouraging. Perhaps I will try building ghc74 on ARM without llvm first, and maybe on Fedora 17 too? Anyway thoughts on how to proceed? Thanks, Jens ps There is actually a proposal to make ARM a Fedora 18 Primary Architecture - though personally I feel it is a bit too early yet - if that happens then this would become a more serious problem, though I know ARM is still not a Tier 1 ghc platform.

3 6

optimizer, spec-constr changes 7.2.2 -> 7.4
by Christian Höner zu Siederdissen 01 May '12

01 May '12

Hi, I am currently trying to get my ADPfusion library to optimize code using ghc-head (same thing described below happens with 7.4.1). Using ghc-7.2.2, both test programs (Nussinov78 and RNAFold) optimize well, the performance is close to C and ghc-core shows good code. This is mostly to say that optimization using ghc-7.2.2 is not an accident but works reliably. Unfortunately, with ghc-head it seems that constructor specialization does not happen. I see a lot of "case x of, Left -> ..., Right -> ..." and "case x of, Yield -> ..." which leads to really bad (slow) code. As there are some discussions going on regarding the optimizer not optimizing (like the ticks exhausted [1] one), are there other changes in the optimizer that could affect it? spec-constr-count / threshold, simplifier phases, simpl-tick-factor, no-liberate-case I have tried... Thanks, Christian PS: This is a ask-first-try-to-find-a-simple-example-later mail ;-) [1] http://hackage.haskell.org/trac/ghc/ticket/5539

1 0