News aggregator

Hello, I just want to be sure of what's the fastest way to reload a module with the GHC API. I have a file whose path is fp I load the module with: addTarget Target { targetId = TargetFile fp Nothing, targetAllowObjCode = True, targetContents = Nothing } Then I load the module load LoadAllTargets And when I want to reload the module (the contents of fp have changed) I do: removeTarget (TargetFile fp Nothing) load LoadAllTargets and then I rerun my initial code (addTarget, load) This works well, I don't get any errors about duplicates, the information I extract from the module is updated properly. But is it the most efficient, or can I achieve the same thing faster (I'm looking at improving the performance of my BuildWrapper code and by consequence of EclipseFP)? Thanks!

Hey, A simple hello world application has 1Mb in by 64 bit ubunut machine. When I stript it, is has about 750kb. When I build a cross compiler for android (arm), the executable has a asize of about 10MB, stripped about 5MB. That is huge, five times the size on my linux sysem. Why is this? Can I do something about it? Thanks! Nathan

hi all, I've been working on GHCJS [1] for a while and am trying to get it to work on 64 bit GHC. A quick background: GHCJS uses the GHC API to generate STG, which it then translates to JavaScript. It uses slightly patched versions of the integer-gmp, base and ghc-prim libraries and supports many GHC features, including arrays and threading. All JavaScript numbers are essentially double precision floating point. With some tricks (using bitwise operators) it's possible to get reasonable 32 bit integer emulation out of it, but emulating 64 bit integers would be very slow. Therefore, if we compile Haskell to JavaScript, it should really be treated as a 32 bit target. Now this is a problem, with GHC 7.6 and lower, generated STG depended on the word size of the host, so it was simply impossible to do this with a 64 bit host. In HEAD, wORD_SIZE_IN_BITS is now in DynFlags, so I decided to have another go. I'm aiming for the following procedure to install GHCJS and build a package: # cabal install ghcjs -- ins

Hey, I am trying to adapt some code in the libraries when compiling for android (i.E. because some things are different on android to other posix systems). So in C code I would just do "#ifdef __ANDROID__". While in the *.h and *.c files it seems to work, it does not work in *.hs files. I noted that the preprocessor is run like this: arm-linux-androideabi-gcc -E -undef -traditional -fno-stack-protector -DTABLES_NEXT_TO_CODE The "-undef" parameter is causing the __ANDROID__ define to be removed. Does it make sense to pass "-undef" to the preprocessor? Any other Ideas how I could adapt the code for android? Thanks! Nathan

Hello, The "validate" script against GHC HEAD freezes on FreeBSD 9.1. After sync-all, I did as follow: ---------------------------------------------------------------- % config_args="--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh validate ---------------------------------------------------------------- This stopped quickly due to this problem: http://hackage.haskell.org/trac/ghc/ticket/7592 Then I executed "validate" with "--no-clean" again. ---------------------------------------------------------------- % config_args="--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh validate --no-clean ---------------------------------------------------------------- GHC could be compiled and tests started. But this result

I'm curious about global constant propagation in GHC.  It's a fairly basic optimization in the CFG-based compiler domain, and it's similar to constructor specialization, but it doesn't seem to be in GHC's repertoire.  Perhaps it's usually subsumed by other optimizations or it's more complicated than I am thinking.  Is this optimization worth implementing? This optimization can help when a case expression returns a product, some fields of which are the same in all branches.  The following program is a minimal example of an optimizable situation that GHC doesn't exploit. {-# OPTIONS_GHC -O3 -funbox-strict-fields #-} data D = D !Int !Int foo n = if n > 0         then D 0 0         else D 0 n main =   case foo $ read "7"   of D x y -> if x == 0 then return () else print y >> putStrLn "A" After inlining and case-of-case transformation, GHC produces main = let n = read "7"            k x y = case x of {0 -> return (); _ -> print y >> putStrLn "A"}        in if n > 0

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!

~d