November 2004 - Glasgow-haskell-users

Compiling Haskell on an UltraSparc/NetBSD
by Stephane Bortzmeyer 15 Nov '04

15 Nov '04

[Not subscribed to haskell-users so please copy me the answers.] To compile the revision control system Darcs (http://www.darcs.net/) I need Haskell but I'm not myself a Haskell user. My machine is an UltraSparc 10 running NetBSD 1.6.2 userland and 2.0 kernel. There is a package source for Glasgow Haskell, so, let's try in /usr/pkgsrc: % make ... checking build system type... sparc64-unknown-netbsd2.0. checking host system type... sparc64--netbsd checking target system type... sparc64--netbsd Unrecognised platform: sparc64--netbsd gmake: Entering directory `/usr/pkgsrc/lang/ghc/work/ghc-6.2.1/glafp-utils' ../mk/boilerplate.mk:66: ../mk/config.mk: No such file or directory You haven't run ./../configure yet. gmake: *** [../mk/config.mk] Error 1 'Unrecognised platform'? But http://www.haskell.org/ghc/docs/latest/html/building/sec-port-info.html says: sparc-unknown-openbsd Supported, including native-code generator. The same should also be true of NetBSD So, what can I try now?

1 0

RE: Problems with CABAL in GHC head.
by Simon Peyton-Jones 15 Nov '04

15 Nov '04

There have been quite a few changes here including new directories. Make sure you cvs update with the "-d" flag, in both ghc/ and libraries/. And make sure all makefiles and autoconf stuff is up to date. then autoreconf and ./configure. Before doing make, go to ghc/driver and 'make clean'. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Keean Schupke | Sent: 15 November 2004 17:37 | To: glasgow-haskell-users(a)haskell.org | Subject: Problems with CABAL in GHC head. | | Trying to recompile GHC (for the template-haskell existential support), but | keeps failing on CABAL (the import for Foreign.Marshal.Alloc is missing | from ghc/lib/compat/Distribution/Version.hs as well as import paths for | Data/Version.hi which is not compiled yet as it depends on ghc-inplace. | | Keean. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Problems with CABAL in GHC head.
by Keean Schupke 15 Nov '04

15 Nov '04

Trying to recompile GHC (for the template-haskell existential support), but keeps failing on CABAL (the import for Foreign.Marshal.Alloc is missing from ghc/lib/compat/Distribution/Version.hs as well as import paths for Data/Version.hi which is not compiled yet as it depends on ghc-inplace. Keean.

1 0

External Core
by Josef Svenningsson 15 Nov '04

15 Nov '04

Dear fellow GHC users, For a number of years GHC has been equipped with the external core language. For those of you who are unfamiliar with this, it is a way to get GHC to emit or read in programs in a format which is very close to its internal intermediate language. This is for instance useful when you want to play with various optimisations. Currently external core is close to an orphan. Nobody is actively maintaining it and it is low on the GHC team's priority list. However, here at Chalmers we have two projects running which depends critically on external core. We have therefore volunteered to adopt external core and take responsibility for it. I will be the organiser of this effort. We are happy for the blessing from the GHC developers and for trusting us with this. We have a number of ideas on how we would like external core. But before putting up an agenda we would like to hear from all the people out there who uses external core. We would be very happy to hear who you are, what you are doing with external core and what changes you might want to see. I'm hoping that we together can work out an external core format which is useful for many people. Hoping to hear from you, /Josef Svenningsson, PhD student at Chalmers, External core tsar

1 0

RE: Looing for advice on profiling
by Simon Marlow 11 Nov '04

11 Nov '04

On 09 November 2004 17:04, Duncan Coutts wrote: >> Are you using BinMem, or BinIO? > > BinIO Aaaaah. BinIO is going to be a lot slower than BinMem, because it does an hPutChar for each character, whereas BinMem just writes into an array. I never really optimised the BinIO path, because we use BinMem exclusively in GHC. Cheers, Simon

3 2

Marshall Multidimensional list, multidimensional array
by David Lo 10 Nov '04

10 Nov '04

Dear all, I have a data of type[[Int]] format, how can I marshal it to int[][] in C using withArray or newArray command ? Some help please. Thank you for your attention and help. Best Regards, David

3 3

Marshall Multidimensional list, multidimensional array Part II
by David Lo 10 Nov '04

10 Nov '04

Dear all, I try to use the following to convert [[Int]] to C's int[][] : foreign export stdcall doCompForeign :: CString -> CString -> IO (Ptr (Ptr Int)) doCompForeign :: CString -> CString -> IO (Ptr (Ptr Int)) doCompForeign patraw cnameraw = let pat = peekCString patraw cname = peekCString cnameraw in doCompHelp pat cname doCompHelp :: IO String-> IO String -> IO (Ptr (Ptr Int)) doCompHelp patIO cnameIO = do pat <- patIO cname <- cnameIO if pat Prelude.== "hns" then (doComp hns cname) else if pat Prelude.== "up" then (doComp up cname) else if pat Prelude.== "down" then (doComp down cname) else if pat Prelude.== "hill" then (doComp hill cname) else (doComp hs cname) doComp :: Pattern -> String -> IO (Ptr (Ptr Int)) doComp pat cname = do (tiPrim,b) <- loadTi cname t1 <- getCPUTime let insts = runVMC (solve (1,b) pat) tiPrim newArray (toArray insts) toArray :: [[Int]] -> [(Ptr Int)] toArray lst = toResultant where toResultant = [toArrayRec (lst!!1)] Prelude.++ toArray (tail lst) toArrayRec :: [Int] -> Ptr Int toArrayRec lst = unsafePerformIO (newArray lst) However, it can compile without problem, however I receive the following error when I run it from C code : Heap exhausted; Current maximum heap size is 268435456 bytes (256 Mb); use `+RTS -M<size>' to increase it. What have I done wrong ? Some help please. Thank you in advance for your help and attention. Best Regards, David Lo

1 0

RE: Looing for advice on profiling
by Simon Marlow 10 Nov '04

10 Nov '04

On 10 November 2004 10:08, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> On 09 November 2004 17:04, Duncan Coutts wrote: >> >>>> Are you using BinMem, or BinIO? >>> >>> BinIO >> >> Aaaaah. BinIO is going to be a lot slower than BinMem, because it >> does an hPutChar for each character, whereas BinMem just writes into >> an array. I never really optimised the BinIO path, because we use >> BinMem exclusively in GHC. > > Is there a method in your Binary library to freeze a BinMem into a > file all in one go? The original nhc98 Binary library allows this > (`copyBin'). Yup, it's called 'writeBinMem'. Cheers, Simon

1 0

RE: proposal for ghc-pkg to use a directory of .conf files
by Simon Marlow 09 Nov '04

09 Nov '04

On 08 November 2004 18:47, Duncan Coutts wrote: > We can use ghc-pkg at the build / install-into-temp phase to create > the $(package).conf files under > $TMP_INSTALL_ROOT/usr/lib/ghc-$VER/package.conf.d/ and then final > installation is jsut merging files without any post-install calls to > ghc-pkg to modify installed files (ie the global ghc package.conf > file) > > So we can still keep the abstraction of $HC-pkg and gain simpler > packaging stuff. Ok, sounds reasonable. I'm going to be working on the package support in ghc and ghc-pkg to improve support for Cabal, so let's do this at the same time. Cheers, Simon

2 1

RE: Looing for advice on profiling
by Simon Marlow 09 Nov '04

09 Nov '04

On 09 November 2004 12:54, Duncan Coutts wrote: [snip] > When I do time profiling, the big cost centres come up as putByte and > putWord. When I profile for space it shows the large FiniteMaps > dominating most everything else. I originally guessed from that that > the serialisation must be forcing loads of thunks which is why it > shows up so highly on the profile. However even after doing the > deepSeq before serialisation, it takes a great deal of time, so I'm > not sure what's going on. let's get the simple things out of the way first: make sure you're compiling Binary with -O -funbox-strict-fields (very important). When compiling for profiling, don't compile Binary with -auto-all, because that will add cost centres to all the small functions and really skew the profile. I find this is a good rule of thumb when profiling: avoid -auto-all on your low-level libraries that you hope to be inlined a lot. You say your instances are created using DrIFT - I don't think we ever modified DrIFT to generate the right kind of instances for the Binary library in GHC, so are you using the instances designed for the nhc98 binary library? If so, make sure your instances are using put_ rather than put, because the former will allow binary output to run in constant stack space. Are you using BinMem, or BinIO? > The retainer profiling again shows that the FiniteMaps are holding on > to most stuff. > > A major problem no doubt is space use. For the large gtk/gtk.h, when I > run with +RTS -B to get a beep every major garbage collection, the > serialisation phase beeps continuously while the file grows. > Occasionally it seems to freeze for 10s of seconds, not dong any > garbage collection and not doing any file output but using 100% CPU, > then it carries on outputting and garbage collecting furiously. I > don't know how to work out what's going on when it does that. I agree with Malcolm's conjecture: it sounds like a very long major GC pause. > I don't understand how it can be generating so much garbage when it is > doing the serialisation stuff on a structure that has already been > fully deepSeq'ed. Yes, binary output *should* do zero allocation, and binary input should only allocate the structure being created. The Binary library is quite heavily tuned so that this is the case (if you compile with profiling and -auto-all, it will almost certainly break this property, though). Cheers, Simon

2 1