- Glasgow-haskell-users

hat, ghc
by Frederik Eaton 02 Sep '05

02 Sep '05

Is there a way to use Hat with GHC, without 'hmake'? The Hat Tutorial shows 'hmake' being used, but 'hmake' doesn't work for me. The problem is that 'hmake' seems to be looking for 'ghc' based on something other than PATH: $ ghc --make pointtracker.hs Chasing modules from: pointtracker.hs Compiling Util ( ./Util.hs, ./Util.o ) Compiling XSimpleIO ( ./XSimpleIO.hs, ./XSimpleIO.o ) Compiling Main ( pointtracker.hs, pointtracker.o ) Linking ... $ which ghc /home/frederik/.toast-i386/armed/bin/ghc $ hmake -hat pointtracker.hs Fail: Can't find module Graphics.X11.Xlib in user directories . Or in installed libraries/packages at /usr/lib/ghc-6.2.2/imports Asked for by: pointtracker.hs Fix using the -I, -P, or -package flags. Stop - hmake dependency error. i.e., I'm not sure how 'hmake' found /usr/lib/ghc-6.2.2, but this directory is not mentioned in my environment, and it was not my intention to use this version of ghc. Thanks, Frederik -- http://ofb.net/~frederik/

3 5

Profiling and analysing space usage
by Alistair Bayley 02 Sep '05

02 Sep '05

Hello all. Below is a (typically pointless) program, which is a small slice from a larger one I'm profiling. I'm interested in getting the memory usage as small as possible. The loop function (and its analogue in the real program) contributes significantly to the allocation stats. AFAICT, this would be mainly due to a closure built for the if-stmt. The heap profile graph for this program shows an initial peak, and then the graph is flat at 8Mbytes, which I think is the space allocated to the two STArrays (2 arrays, 1 million chars each, 4 bytes per char?). So it looks as though any allocation for the loop function is GC'd very soon after it's allocated. So my questions are: - is my analysis of the space usage correct i.e. allocation in the loop function is very short-lived and nothing to worry about? - is there anything I can do to reduce the memory usage, or is it already minimal, assuming that I'm happy with the size of the STArrays? I realise I could use, say, PackedStrings, but the original program works on lists of (Eq a); I've just chosen Chars for this example so as to eliminate polymorphism from the profiling. Notes: - exporting only main makes a *big* difference to both space and time usage, as does adding type signatures, to eliminate polymophism. This is the only retainer set shown on the profiling graph: SET 2 = {<MAIN.SYSTEM>} COST CENTRE MODULE %time %alloc loop Main 35.1 15.4 alloc_b Main 19.5 7.7 main Main 13.0 30.8 makeArray1 Main 9.1 5.1 loop_if Main 9.1 41.0 inBounds Main 6.5 0.0 test1M Main 3.9 0.0 alloc_a Main 3.9 0.0 module Main (main) where import Data.Array.ST import Control.Monad.ST main :: IO () main = do let src = take 1000000 (repeat 'a') dst = take 1000000 (repeat 'a') d :: Int d = test1 src dst print d test1 :: String -> String -> Int test1 src dst = runST (test1M src dst) test1M :: String -> String -> ST s Int test1M src dst = do srca <- makeArray1 (length src) src dsta <- makeArray1 (length dst) dst loop srca dsta 1 inBounds :: STArray s Int Char -> Int -> Bool inBounds arr i = case bounds arr of (l, u) -> i >= l && i <= u makeArray1 :: Int -> [Char] -> ST s (STArray s Int Char) makeArray1 len str = newListArray (1, len) str loop :: STArray s Int Char -> STArray s Int Char -> Int -> ST s Int loop srca dsta n = do if (inBounds srca n) && (inBounds dsta n) then do a <- {-# SCC "alloc_a" #-} readArray srca n b <- {-# SCC "alloc_b" #-} readArray dsta n {-# SCC "loop_if" #-} if a == b then (loop srca dsta (n+1)) else (return n) else return n

3 2

RE: Profiling under 6.4.1 and Solaris segfaults
by Simon Peyton-Jones 02 Sep '05

02 Sep '05

Does this happen on anything other than Solaris? We don't have local access to Solaris hardware at the moment. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Nils Anders Danielsson | Sent: 29 August 2005 18:04 | To: glasgow-haskell-users(a)haskell.org | Subject: Profiling under 6.4.1 and Solaris segfaults | | Running a simple Hello World program compiled with a GHC 6.4.1 | snapshot (20050820) and profiling turned on (-prof -auto-all) under | Solaris results in a segfault. The core dump is similar to a core dump | posted earlier | (http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg04621.h tml): | | (gdb) where | #0 0x0003df8c in EnterFunCCS () | #1 0x0004a714 in stg_PAP_info () | #2 0x00045538 in schedule () | #3 0x00045ff8 in waitThread_ () | #4 0x00045f48 in scheduleWaitThread () | #5 0x0004258c in rts_evalLazyIO () | #6 0x0003bea8 in main () | | The other core dump was due to not compiling the entire program with | profiling turned on. However, the profiling libraries are installed, | so I see no reason why that should be the case now. On the other hand, | when I compile with -fno-implicit-prelude (and main = main), I don't | get a core dump. | | Have other Solaris users experienced something similar? I don't have | any problems with the Linux snapshot from the same day. | | -- | /NAD | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: problem compiling programs with monads with ghc-6.4
by Konovalov, Vadim 31 Aug '05

31 Aug '05

> Add -package mtl ? thanks, that worked... So, I do not need to "improve" my configuration, but rather I should remember in which package live some functions, and specify those each time? ok, thanks. > > vkonovalov: > > Dear all, > > > > When I compile simple programs with monads, I receive > following error: > > > > example18.o(.text+0x2de):fake: undefined reference to > > `ControlziMonadziCont_zdfMonadContCont_closure' > > example18.o(.text+0x422):fake: undefined reference to > > `ControlziMonadziCont_zdfMonadContCont_closure' > > example18.o(.text+0x16f5):fake: undefined reference to > > `__stginit_ControlziMonadziCont_' > > example18.o(.data+0xa8):fake: undefined reference to > > `ControlziMonadziCont_zdfMonadContCont_closure' > > example18.o(.data+0xe8):fake: undefined reference to > > `ControlziMonadziCont_zdfMonadContCont_closure' > > > > When I do > > ghc E:\apps\ghc-6.4\libHSmtl.a -o example18.exe example18.hs > > all is fine. > > > > For some reasons, libHSmtl.a is not seen by default. > > > > What I am missing? > > > > I feel this is configuration problem, but I afraid editing > "package.conf" or > > alike, because I'll probably make situation worse. > > > > TIA. > > > > Best regards, > > Vadim. > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

problem compiling programs with monads with ghc-6.4
by Konovalov, Vadim 31 Aug '05

31 Aug '05

Dear all, When I compile simple programs with monads, I receive following error: example18.o(.text+0x2de):fake: undefined reference to `ControlziMonadziCont_zdfMonadContCont_closure' example18.o(.text+0x422):fake: undefined reference to `ControlziMonadziCont_zdfMonadContCont_closure' example18.o(.text+0x16f5):fake: undefined reference to `__stginit_ControlziMonadziCont_' example18.o(.data+0xa8):fake: undefined reference to `ControlziMonadziCont_zdfMonadContCont_closure' example18.o(.data+0xe8):fake: undefined reference to `ControlziMonadziCont_zdfMonadContCont_closure' When I do ghc E:\apps\ghc-6.4\libHSmtl.a -o example18.exe example18.hs all is fine. For some reasons, libHSmtl.a is not seen by default. What I am missing? I feel this is configuration problem, but I afraid editing "package.conf" or alike, because I'll probably make situation worse. TIA. Best regards, Vadim.

2 1

RE: Character index vs Column number in GHC error messages
by Bayley, Alistair 31 Aug '05

31 Aug '05

> From: Krasimir Angelov [mailto:kr.angelov@gmail.com] > > The difference comes from the tab > characters which can have different width depending from the editor > settings. For such reason all compilers, which I am aware of, display > the character index instead of column number. ... GHC displays the > column number instead and this confuses the editors. Dude! Don't use tabs :-) ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

Character index vs Column number in GHC error messages
by Krasimir Angelov 31 Aug '05

31 Aug '05

Hello, Guys Quite recently GHC was changed to display the column number as well as the line number in all error messages. This is useful feature but I found the following difficulty with using it. All text editors that have built-in support for compilers, expect to find the line number in the reported error messages. Some of them support column number as well, but actually this isn't the column number but the character index in the current line. The difference comes from the tab characters which can have different width depending from the editor settings. For such reason all compilers, which I am aware of, display the character index instead of column number. I tried this with C#, Visual Basic and GNU CPP. GCC, Sun's Java compiler and Visual C++ compiler are displaying only the line number. Using the character index the editor can unambiguously find the exact position where the error is independently from the current tab setting. GHC displays the column number instead and this confuses the editors. At least I tried this with Visual Studio and TextPad editor. I have modified the GHC parser so that it displays the character index instead of column number, but I am curious whether this is the preferred behaviour of the other compilers/editors. Any thoughts are appreciated. Cheers, Krasimir

1 0

Automatically derived instances
by Juan Carlos Arevalo Baeza 29 Aug '05

29 Aug '05

(BCC'ing the GHC bugs list) It seems like there's something very funky going on with GHC (6.4) and automatically deriving instances. Consider this code: ---8<-------------------------------------- 1: class MyClass a 2: 3:instance MyClass a => Show a 4: 5:newtype Type1 = Type1 { unType1 :: Int } deriving (Show) 6: 7:main = putStrLn $ show $ Type1 4 ---8<-------------------------------------- If you try to compile this, you get: ---8<-------------------------------------- Overlapping instances for Show Int arising from the 'deriving' clause of a data type declaration at Test.hs:5:8 Matching instances: Test.hs:3:0: instance (MyClass a) => Show a Imported from GHC.Show: instance Show Int When deriving the `Show' instance for type `Type1' ---8<-------------------------------------- Weird error. I haven't even declared an instance of MyClass! If I change line 5 to "deriving (MyClass), I get: *** Exception: stack overflow Sounds like a compiler bug to me. If I comment out line 3 and leave "deriving (Show)", it all works as expected. So... what's exactly the purpose of omitting the where-part of an instance declaration? It is supported, and it is even shown in code in the Haskell 98 report, but I failed to find any place in the whole document where it was described. Same thing for GHC's documentation. My purpose here was to do group classes for deriving like so: ---8<-------------------------------------- class MyNum a instance MyNum a => Eq a instance MyNum a => Ord a instance MyNum a => Show a instance MyNum a => Enum a instance MyNum a => Num a instance MyNum a => Real a instance MyNum a => Integral a instance MyNum a => Bits a instance MyNum a => Storable a -- Too long?... newtype ID = ID { unID :: WORD } deriving (Eq, Ord, Show, Enum, Num, Real, Integral, Bits, Storable) newtype ID = ID { unID :: Int } deriving (MyNum) ---8<-------------------------------------- I guess that's not doable? JCAB

3 3

Profiling under 6.4.1 and Solaris segfaults
by Nils Anders Danielsson 29 Aug '05

29 Aug '05

Running a simple Hello World program compiled with a GHC 6.4.1 snapshot (20050820) and profiling turned on (-prof -auto-all) under Solaris results in a segfault. The core dump is similar to a core dump posted earlier (http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg04621.html) (gdb) where #0 0x0003df8c in EnterFunCCS () #1 0x0004a714 in stg_PAP_info () #2 0x00045538 in schedule () #3 0x00045ff8 in waitThread_ () #4 0x00045f48 in scheduleWaitThread () #5 0x0004258c in rts_evalLazyIO () #6 0x0003bea8 in main () The other core dump was due to not compiling the entire program with profiling turned on. However, the profiling libraries are installed, so I see no reason why that should be the case now. On the other hand, when I compile with -fno-implicit-prelude (and main = main), I don't get a core dump. Have other Solaris users experienced something similar? I don't have any problems with the Linux snapshot from the same day. -- /NAD

1 0

Re: "#!..." (Re[2]: cabal configure screw-up)
by Seth Kurtzberg 29 Aug '05

29 Aug '05

Frederik Eaton wrote: >>But it isn't running "in a unix emulation environment." cygwin is >>simply _not_ such an environment. The program is started by a different >>shell, but that is _not_ an emulation environment. >> >> > >Is it an elephant? A tree? > > I guess the most accurate way to describe it is that it tries to emulate the _development_ environment of UNIX. It has gnu make and various other utilities and shells compiled to run under win32. So you can build things that rely on shell scripts, because the shell scripts are executed by either (1) a shell, which knows the conventions about how to execute scripts or (2) the make utility, which similarly has been forced to behave such that makefiles that rely on scripting still work. This does not, unfortunately, extend to the run time environment. That's why I said it isn't an emulation environment. A program that is executing is not different in any way from any other native win32 program that is executing. A program could be set up to check whether it was started from a UNIX like shell, by querying it's parent process, but obviously this has problems. O/S functions, such as the ones that allow one process to execute another process, are unmodified. There is no library that intersperses itself between the process and the O/S. So there is really no way to change the O/S behavior, specifically with regard to running scripts, but more generally in any way. >Frederik > > >

1 0