- Glasgow-haskell-users

Build failure of syb-with-class with ghc-7.2.1
by Bas van Dijk 09 Aug '11

09 Aug '11

Hello, the HEAD of syb-with-class fails with the following error when build with ghc-7.2.1 and template-haskell-2.6: http://code.google.com/p/syb-with-class/issues/detail?id=4 Is this a bug in TH? Regards, Bas

4 6

7.2.1-rc1 fails to build on kfreebsd-*, mips*, s390 and sparc
by Joachim Breitner 07 Aug '11

07 Aug '11

Dear GHC team, I have uploaded 7.2.1-rc1 to Debian experimental. It build fine on i386, amd64 and powerpc, but fails on the other architectures: https://buildd.debian.org/status/package.php?p=ghc&suite=experimental („last log“ gives you the full build log) The causes seem to be different. On kfreebsd, we get: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.2.0.20110728 for i386-unknown-kfreebsdgnu): Don't know if OSUnknown is elf This might be something that is easy to fix in compiler/utils/Platform.hs, but you will know better if one should add a new OS value, or reuse OSFreeBSD. On the other architectures there are complaints about static declarations following non-static declaration that I do not understand. I hope you do :-) With best regards, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 1

-fllvm
by Luca Ciciriello 06 Aug '11

06 Aug '11

Hi all. I'm trying to build my Haskell code using llvm option, but using the command: ghc --make -O2 -fllvm Main.hs -o myapp I get the following warning: Warning: -fllvm is incompatible with -fPIC and -dynamic on this platform; ignoring -fllvm I'm using GHC 7.0.4 (64-bit) on MacOS Lion (10.7) with Xcode 4.1. Thanks in advance for any answer. Luca.

2 2

GHCJS
by Victor Nazarov 05 Aug '11

05 Aug '11

Hello, I'm a maintainer and creator of GHCJS tool [1]. GHCJS currently uses GHC API to produce Javascript code from Haskell sources. There is a great interest to the project, but there have been little progress recently. I'm considering the future of it and I'd like to get some advices or suggestions from GHC maintainers. GHCJS originally was fork of GHC 6.6 with javascript generation built in. Since javascript generation is very experimental, I wasn't trying to push it into GHC mainline. Besides it was expressed several times [2] that GHC HQ doesn't want to support another backend which brings lots of interoperability problems with it. Since then GHCJS switched to GHC API. For now code generation works decently well. But I have many problems that I'd like to solve and I'm not sure if it is feasible using GHC API, == Command line interface == I'd like to reproduce GHC command line interface for GHCJS tool. For now I'm using something like this: main :: IO () main = do args <- getArgs defaultErrorHandler defaultDynFlags $ runGhc (Just GHC.Paths.libdir) $ do sdflags <- getSessionDynFlags (dflags, fileargs, _) <- parseDynamicFlags sdflags (map noLoc args) _ <- setSessionDynFlags dflags let fileargs' = map unLoc fileargs targets <- mapM (flip guessTarget Nothing) fileargs This works, but I'm not allowed to parse some custom flags used by GHCJS code and not by GHC API. ParseDynamicFlags throws UsageError if it encounters some unknown flags. What can I do to extend GHC's command line arguments' syntax with some custom arguments used by GHCJS? I can parse arguments myself and throw the rest of them to parseDynamicFlags, but GHC's flags are really complicated and I'm not aware of any argument parsing library that can be used to filter out some specified flags and return the rest GHC's flags untouched. == Foreign Function Interface == What I want is to provide FFI for Javascript, But GHC doesn't allow to extend FFI declaration syntax. I'd like to create some new FFI calling convention ("javascript") like this: foreign import javascript "alert" jsalert :: Ptr JSString -> IO () But GHC always emit parse error on "javascript" keyword. For now I'm using (abusing) ccall calling convention and simple imports works pretty well, but I would like to support exports and static/dynamic wrappers. GHC generates C-code to support them, and GHCJS should generate Javascript-code, but I have no idea how to use GHC API to generate custom (Javascript) stubs. Is it possible at all? == Packages support == It will be very handy if users can use Cabal to install and build packages with GHCJS. It should work if I replicate ghc and ghc-pkg command line interface, but remaining problem is that package index and package directories will be shared with GHC, I'd like to create ghcjs and ghcjs-pkg tools that will use their own directories and package index and will not interfere with ghc. Is it possible with GHC API? How can I do it? [1] https://github.com/sviperll/ghcjs [2] http://www.haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.N… -- Victor Nazarov

8 17

System.Process.system in Windows
by wagnerdm＠seas.upenn.edu 04 Aug '11

04 Aug '11

Hello all, I had a bit of fun recently tracking down quoting issues with the "system" command in Windows. For the examples below, I'll consistently use "Windows> " as the beginning of some text sent to the Windows command prompt cmd.exe, and use "GHC> " as the beginning of some text sent to a ghci session running in cmd.exe with System.Cmd imported. The situation is this: I want to hand off a command line which has both a possibly-quoted command name and a (definitely) quoted argument. For concreteness, let's use "more" as the command and "foo.txt" as the argument, so that you can follow along at home on your favorite Windows system. Windows> echo foo > foo.txt Windows> "more" "foo.txt" foo All good so far. But: GHC> system "\"more\" \"foo.txt\"" 'more" "foo.txt' is not recognized as an internal or external command, operable program or batch file. ExitFailure 1 After some digging, I discovered that system is shipping out to cmd /c, and indeed: Windows> cmd /c "more" "foo.txt" 'more" "foo.txt' is not recognized as an internal or external command, operable program or batch file. I don't know what the *right* fix is. However, after a bit of playing around, I discovered the following: Windows> cmd /c ""more" "foo.txt"" foo GHC> system "\"\"more\" \"foo.txt\"\"" foo ExitSuccess Wrapping commands with an extra pair of double-quotes this way seemed to give behavior matching the bare cmd.exe for all the examples I could think of, even ones I thought it would break. For example: GHC> system "\"more foo.txt\"" foo ExitSuccess If this turns out to be the right thing to do, it's pretty easy to implement. In the commandToProcess function, at libraries/process/System/Process/Internals.hs:455, the change is just - return (cmd, translate cmd ++ "/c " ++ string) + return (cmd, translate cmd ++ "/c \"" ++ string ++ "\"") (And in any case, the examples above should answer this amusing comment, immediately following those lines: -- We don't want to put the cmd into a single -- argument, because cmd.exe will not try to split it up. Instead, -- we just tack the command on the end of the cmd.exe command line, -- which partly works. There seem to be some quoting issues, but -- I don't have the energy to find+fix them right now (ToDo). --SDM -- (later) Now I don't know what the above comment means. sigh. =) ~d

3 2

occasional linking problems with --make?
by Evan Laforge 03 Aug '11

03 Aug '11

I'm just wondering if other GHC users see the errors I see. Occasionally, a program will fail to link, with an error similar to the following: Linking build/test/RunTests ... lUndefined symbols: "_UiziRulerC_dk8C", referenced from: _skev_info in RulerC.o ld: symbol(s) not found collect2: ld returned 1 exit status The program involves some C FFI, the Ui.RulerC module mention above is one such FFI-using module. It's consistent in that if I do another 'make' I'll keep seeing the error, but inconsistent in that if I rm a bunch of .o files to force them to recompile, I usually get a successful link afterwards. I haven't really figured out what exact files I need to rebuild, but I don't think it's necessarily just the "referenced from" module, on occasion deleting a bunch of files doesn't solve the problem and I just do a 'make clean'. I haven't noticed if it's always FFI using modules, or which exact .o files I have to delete to fix the problem, but I'll pay more attention in the future. I've been seeing this problem pretty regularly (maybe once every couple of weeks) since upgrading to ghc7 a long time ago. Do other people see this same issue? Is there something I can do to better track it down, other than the two things I mentioned above? I'd like to blame my hacky makefile, but then again all the haskell modules use --make so it seems like ghc is to blame. Also, when I remove an import from a module I can fairly reliably get the "modules below me: missing <module no longer imported>, hi files probably out of date" warning from every module above. It's annoying but seems to be harmless, and when I get tired of the noise I do a make clean. Is this a common problem? I feel like there's something wrong in the dependency tracking that yields these problems. This is ghc 7.0.2, btw.

2 3

Why no stack overflow in ghci?
by Roman Cheplyaka 03 Aug '11

03 Aug '11

The code main = print $ foldl (+) 0 [1..1000000] when compiled (without optimizations) results in a stack overflow, which is expected. However, when run from ghci it succeeds. Why is it so? (Tested with GHC 6.12.something and 7.0.4) Is it related to "stack-squeezing"? I couldn't find any description of it, apart from a few bug reports. A related question: how can I control the stack size in evaluations inside ghci? Is it (roughly) the same as setting the ghci's own stack size by passing -K to it in the command line? -- Roman I. Cheplyaka :: http://ro-che.info/

3 3

haskell-platform configures failed on Ubuntu 11.04
by David Smith 01 Aug '11

01 Aug '11

I tried to build the newest haskell-platform-2011.2.01 from source on Ubuntu 11.04, following the instructions http://www.vex.net/~trebla/haskell/haskell-platform.xhtml. But there was still an configure error. $ ./configure ************************************************** * * Haskell Platform Source Installer * * For the Haskell Platform 2011.2.0.1 and GHC 7.0.3 * ************************************************** checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for ghc... /usr/local/bin/ghc checking for ghc-pkg... /usr/local/bin/ghc-pkg checking for hsc2hs... /usr/local/bin/hsc2hs checking version of ghc... 7.0.3 checking version of ghc-pkg matches... yes checking ghc actually works... [1 of 1] Compiling Main ( conftest.hs, conftest.o ) yes checking the ghc core packages are all installed... yes checking for perl... /usr/bin/perl checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for zlibVersion in -lz... yes checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking for library containing glEnd... no configure: error: The OpenGL C library is required In fact, glEnd function did exist in /usr/include/GL/gl.h I googled this issue, only found this one is similar to mine, but my system is Ubuntu not Opensus http://haskell.1045720.n5.nabble.com/Haskell-Platform-can-t-use-OpenGL-on-O… The following are the libraries I already installed sudo apt-get install libgl1-mesa-dev sudo apt-get install libglc-dev sudo apt-get install freeglut3-dev sudo apt-get install libedit-dev sudo apt-get install libglw1-mesa libglw1-mesa-dev Can anyone suggest the libraries my OS missing ?

3 2

integer-simple
by Chris Dornan 31 Jul '11

31 Jul '11

Hi All, I am still having difficulty getting a plain GHC build with INTEGER_LIBRARY = integer-simple. (I outlined my problem here yesterday <http://www.haskell.org/pipermail/glasgow-haskell-users/2011-July/020631.htm l> .) I suspected my failure to get a vanilla build (with GMP) was a minor issue with RHEL 5 and indeed a vanilla build of the the compiler goes through no problem on RHEL 6, producing a working 6.12.3 GHC installation. But when I repeat with INTEGER_LIBRARY = integer-simple (on quick test) I get (the now familiar): GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. ghc: /usr/local/ghc/6.12.3-si/lib/ghc-6.12.3/integer-simple-0.1.0.0/HSinteger-sim ple-0.1.0.0.o: unknown symbol `base_ControlziExceptionziBase_patError_info' Loading package integer-simple ... linking ... ghc: unable to load package `integer-simple' RHEL 5 and 6 are very different development environments yet all my attempts to build with a variety of source trees from 6.12.1 to 7.0.4 with INTEGER_LIBRARY = integer-simple has ended here. There is clearly something I am doing wrong! (Though it is difficult to see what.) Does anybody have any idea what could be causing this? Is anybody else doing integer-simple builds? It would be nice to get some info on the configurations that are working. Thanks in advance! Chris

4 7

possible strictness bug in profiled version of a program
by Peter Hercek 30 Jul '11

30 Jul '11

Here is a test program (file name prgSrc.hs): import Data.Array.Unboxed main = do let l1 = [1..10] :: [Int] let l2 = [ map (i+) l1 | i <- [1..5000000] ] let l3 = map (\l -> listArray (1,length l) l) l2 :: [UArray Int Int] print $ accumulate l3 0 accumulate [] rv = rv accumulate (h:t) rv = let nextRv = (rv + sum (elems h)) in accumulate t $! nextRv I used ghc 7.0.3-2 on archlinux, 64 bit version. I created it only to check how much memory short unboxed arrays consume. Thanks to the "$!" call at the last line of the "accumulate" function there should not be any stack overflow. When I compile with these options: --make prgSrc.hs -O2 --make prgSrc.hs -prof -auto-all -caf-all --make prgSrc.hs then there is no problem. But when I compile with these options: -O2 -prof -auto-all -caf-all --make prgSrc.hs then program runs out of stack. This indicates that there is a bug while compiling "$!" in an optimized profiling version of this program. Is it a bug? Should it be reported to the ghc trac database? Peter.

2 2