April 2002 - Glasgow-haskell-users

ghc5.03 .hi and .hi-boot files don't you just love those incompatible changes?
by George Russell 16 Apr '02

16 Apr '02

Formerly .hi and .hi-boot files had the same format; however ghc5.03 has a binary format for .hi files and a textual one for .hi-boot files. This is a nuisance for me, because I have an ingenious scheme by which .hi-boot files are themselves from Haskell files by ghc, which thinks it is generating .hi files. Since I don't particularly want to go from writing to Haskell to writing interface files, I would like to keep the old scheme, but then I need a way of getting GHC to generate .hi-boot files from .hs files. One might think the options -ddump-hi or --show-iface would do the job, but they don't. --show-iface produces a file which causes Haskell later to choke with the message failed to load interface for `DisplayView': Bad interface file: DisplayView.hi-boot DisplayView.hi-boot:1: parse error on input `__interface' -ddump-hi is even worse, since it adds an extra two totally useless lines at the start (but otherwise appears to be the same as --show-iface). So is there any way of getting GHC to generate .hi-boot files? Or should I give up on using .hi-boot altogether and simply compile the Haskell direct to the .hi file?

1 1

hsc2hs does not fail
by Axel Simon 16 Apr '02

16 Apr '02

Hi, for some reason hsc2hs does not fail if the automatically generated program fails to execute. This only happends if I forget to set LD_LIBRARY_PATH before saying make. But it leads to a confusing error messages when an empty .hs file is left and ghc complaints with "file name does not match module name". The patch below was done against ghc-5.02.2 on FreeBSD. Cheers, Axel. *** Main.hs~ Fri Sep 14 17:15:11 2001 --- Main.hs Tue Apr 16 11:29:28 2002 *************** *** 504,510 **** _ -> return () removeFile oProgName ! system (execProgName++" >"++outName) removeFile progName when needsH $ writeFile outHName $ --- 504,513 ---- _ -> return () removeFile oProgName ! progStatus <- system (execProgName++" >"++outName) ! case progStatus of ! e@(ExitFailure _) -> exitWith e ! _ -> return () removeFile progName when needsH $ writeFile outHName $

1 0

no digest
by Serge D. Mechveliani 16 Apr '02

16 Apr '02

Tim, You write > I'm trying to build DoCon which requires Haskell. > > Actually, I now understand the problem better. > Haskell requires happy to build. > happy requires Haskell to build. > (ldl is a compiler switch to haskell /usr/bin/ghc -ldl) > So I need to install Haskell before I can build Haskell. > I've installed it and am trying to continue the build. Generally, concerning Glasgow Haskell (ghc) installation and usage, ask glasgow-haskell-users(a)haskell.org They know GHC and Haskell much better and will help promptly. Explain them what system and processor you have. GHC compiles and `makes' itself. And for the first time, you need to install Glasgow Haskell (ghc) from binary distribution, not from source. Take from http://haskell.org/ghc/ the binary distribution appropriate to your system (Linux, Intel ... ?) DoCon needs version ghc-5.02.2 or ghc-5.02.3 If you have Debian Linux, then install ghc-5.02.2 from the package of Debian distribution. Binary installation does not require the Happy parser to be installed earlier. Then, see install.txt of DoCon. Also I shall help - only, after about April 25. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

max heap exhausted
by Hal Daume III 15 Apr '02

15 Apr '02

What does it mean when my program tells me: "fatal error: RTS exhausted max heap size (268435456 bytes)" ? My initial understanding was the GHC allocated (perhaps dynamically) a heap of unlimited size (at least so says +RTS -help) and when I run my (long memory grabbing) program without any RTS flags it gets about 1/4 of the way done (on my Windows box -- this is ghc5.03 the original snapshot) and then tells me this. So I go to increase the heap (i have 1g of ram) so I say "+RTS -H512m" and immediately it comes back to me with the same error (presumably in trying to allocate the heap?). I think there are really two error messages going on here: the first is truly that the heap is exhausted, but the second is more of "I can't allocate that much". Am I correct? If so, why not? I can run it with -H300m, but not -H350m (on the first RTS doesn't complain until later; on the second it complains immediately). How can I give my program more heap and why does -H300m give it more heap than without any RTS options which should give it unlimited heap? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 2

Re: New Patches & Binary for MacOS X
by Wolfgang Thaller 15 Apr '02

15 Apr '02

The binary package for MacOS X is now available at http://www.kfunigraz.ac.at/imawww/haskell/GHC.dmg Enjoy! -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

1 0

ghc-pkg (5.03.20020204) problems
by George Russell 15 Apr '02

15 Apr '02

Can you stop ghc-pkg complaining when it can't find the library for a package, and insert the package into its configuration file? Some of my scripts rely on being able to build the package.conf file ahead of time. What with this, and because ghc-pkg doesn't seem able to cope with private config files (see previous report) ghc-pkg in 5.03 is causing me lots of problems.

1 0

New Patches & Binary for MacOS X
by Wolfgang Thaller 15 Apr '02

15 Apr '02

Here are some new patches for GHC for MacOS X. The patches are relative to the CVS HEAD from 9th of April. I also have prepared a binary snapshot [a double-clickable installer package this time], but as last time, I don't have the webspace to upload it myself - I'd be happy to FTP it wherever there might be 25 megs of webspace available for it. What's new in this version: *) foreign export dynamic: createAdjustor now flushes the instruction cache, this should fix some crashes. *) Profiling now works. *) improved mangling: the mangler now _completely_ removes all references to __DISCARD__. *) Much simpler (and perhaps more compatible) code for detecting MacOS X memory layout (-27 +5 lines of code). The following are not really new, but not in CVS: *) Completely new implementation of StgRun (fixes some serious segfaults). *) Added a missing #include "config.h" to AbsCUtils.lhs - this should fix a bug for all Big-Endian platforms. *) Brutal changes to ClosureFlags.c to make it compile with Apple's strange version of gcc. What's still missing: *) --split-objs *) GHCi Cheers, Wolfgang

1 0

-O2
by Saswat Anand 15 Apr '02

15 Apr '02

Hi, In my program I observe that, with -O2 flag turned on, Program 1 behaves like Program 2. And without O2, their outputs are different. Is it the desirable behaviour? For my program, I did not expect the optimizer to do this transformation. Thanks, Saswat Program 1: eval = \..-> let t = some_long_expression tree q = Tree (w:=q) some_long _expression in if w /= 0 then concatMap (cc con1) [tree x | x <- [1..n]] else t Program 2: eval = \..-> let t = some_long_expression tree q = Tree (w:=q) t -- Here is the difference in if w /= 0 then concatMap (cc con1) [tree x | x <- [1..n]] else t some_long_expression stands for, concatMap (cc con2) $ zipWith join (eval v c1 (reverse v1)) (eval v c2 v2)

1 0

handling of multibyte char strings
by Jens Petersen 14 Apr '02

14 Apr '02

GHC 5.02.[23] seems to be quite strict about literal strings in source code. I presume this is a feature. :-) However this is annoying for people who want to use wide chars in strings in source code. (Though I realise that doing so is not very "portable".) To illustrate, the following program main :: IO () main = let ja = 'Japanese character' in putChar ja >> putChar '\n' results in Compiling Main ( test-ja.hs, interpreted ) test-ja.hs:3: error in character literal Failed, modules loaded: none. with both ghc and ghci. Is anything allowed in literal strings except ascii? utf-8? Jens

3 2

RE: An answer and a question to GHC implementors [was Re: How to make Claessen's Refs Ord-able?]
by Simon Marlow 11 Apr '02

11 Apr '02

> > However, it is possible to have global top-level references using > > unsafePerformIO if you're very careful about it. In GHC we > do something > > like this: > > > > {-# NOINLINE global_var #-} > > global_var :: IORef Int > > global_var = unsafePerformIO (newIORef 42) > > > > the NOINLINE pragma is used to ensure that there is > precisely *one* copy > > of the right hand side of global_var in the resulting > program (NOTE: you > > also need to compile the program with -fno-cse to ensure that the > > compiler doesn't also common up the RHS of global_var with > other similar > > top-level definitions). > > this usage of unsafePerformIO is such a staple of real-world Haskell > programming, it seems there should be some language (or experemental > compiler *wink wink ghc nudge*) support for it. I am not sure > what form > it would take though. <muse> I did wonder once whether IO monad bindings should be allowed at the top-level of a module, so you could say module M where ref <- newIORef 42 and the top-level IO would be executed as part of the module initialization code. This solves the problems with unsafePerformIO in a cleanish way, but would add some extra complexity to implementations. And I'm not sure what happens if one top-level IO action refers to other top-level IO bindings (modules can be recursive, so you could get loops too). </muse> > getGlobalVar :: IO (IORef Int) > getGlobalVar = memoIO (newIORef 42) > > note that this is not exactly the same since getting the global var is > in the io monad, but that really makes sense if you think > about it. and > chances are you are already in IO if you need an IORef. This doesn't really solve the problem we were trying to solve, namely that passing around the IORef everywhere is annoying. If we were happy to pass it around all the time, then we would just say main = do ref <- newIORef 42 ... pass ref around for ever ... We could use implicit parameters, but that means changing the types of lots of functions, and that's just as annoying as actually passing the arguments around explicitly. Cheers, Simon

3 2