- Glasgow-haskell-users

RE: RFC: hyperlinks in Haddock docs
by Simon Marlow 24 Feb '05

24 Feb '05

On 22 February 2005 19:37, Duncan Coutts wrote: > Excellent! Thanks a lot. > > Any hint as to when the next Haddock release will be? Maybe when I've got this GHC release out of the way and my hair has grown back :-S Simon

2 1

RE: GHC 6.4 release candidates available (breakage on suse 9.2 x86or x86-64)
by Simon Marlow 24 Feb '05

24 Feb '05

On 24 February 2005 02:38, Wolfgang Thaller wrote: > So maybe x86-Linux needs a ghc binary with as few library dependencies > as possible, to facilitate bootstrapping on different Linux distros? That's a good idea. GHCi doesn't work if the GHC binary is linked with -static, so we'll have to make a separate statically-linked binary distribution, though. Cheers, Simon

1 0

RE: Help with a Shootout program
by Simon Marlow 24 Feb '05

24 Feb '05

On 24 February 2005 14:47, Carsten Schultz wrote: > The real performance problem propbably is not O(n) vs. O(n*log n) but > slow String operations in general. After all, String is a lazy list > of Char. Have a look at the thread mentioned above, possibly Simon's > version has become fast again, otherwise it would be an opportuniy to > reconsider the problems mentioned there. PackedStrings are still slow in 6.x. I know there are various other PackedString implementations out there, we just need to incorporate one. Cheers, Simon

1 0

RE: GHC 6.4 release candidates available (breakage on suse 9.2 x86 or x86-64)
by Simon Marlow 24 Feb '05

24 Feb '05

On 24 February 2005 11:12, Malcolm Wallace wrote: > Ideally, if ghc were implemented in something closer to Haskell'98, > it would be possible to double-bootstrap up from gcc -> nhc98 -> > ghc unregisterised -> ghc registerised, on almost any new platform. > But the amount of work required to 98-ify ghc is considerable (there > are 148 kLoC to check), and it is hard to say whether it would > be worthwhile. Maybe someone fancies tackling it as a medium-size > project? It's feasible, but unfortunately probably not practical. Not only would someone have to do the work, we'd have to maintain the Haskell 98 version too. That's yet another way to build GHC, and there are already too many variables for us to test them all. However, a more reasonable approach might be to remove the platform dependencies from GHC and the libraries it requires for bootstrapping. That is, make it so that unregisterised .hc files are platform-independent. I think we used to have this property in the distant past, but it got lost somewhere along the way. It would mean banishing platform differences into C code wherever necessary, which would result in more C code and less Haskell code, but it might be worthwhile. Cheers, Simon

1 0

Help with a Shootout program
by Alson Kemp 24 Feb '05

24 Feb '05

All, In order to teach myself Haskell, I've been tinkering with some of the Shootout (http://shootout.alioth.debian.org/great/) programs. Substantially improved the Mandelbrot program. Then started to work on the Spellcheck program, since Haskell seemed to do quite poorly at it. However, my revision appears to be slower than the original. I was hoping that I could get some help from y'all. Original program: import Data.Set main = do d <- readFile "Usr.Dict.Words" let misspelled x = not $ x `elementOf` (mkSet (lines d)) interact $ unlines . filter misspelled . Lines The original program is nice and short, but uses Set to hold the 80,000 word dictionary. The Input file is 80,000 words, too, so I figured that searching the Set dictionary would be an O(n^2) task (80,000 spellchecks x linear search on 80,000 word dictionary Set). All of the other languages used hash tables for this task (O(n) (80,000 spellchecks x hash search on dictionary), so I revised the program to do the same. ---------------------------------------- Revised program: import Data.HashTable import IO import GHC.Int buildHash :: (String -> Int32) -> String -> IO (HashTable String Bool) buildHash hash_fn list = do table <- new (==) hash_fn sequence_ [ insert table k True | k <- lines list ] return table spellcheck :: HashTable String Bool -> String -> String -> IO String spellcheck ds "" accum = return accum spellcheck ds xs accum = let (x, xs') = break (== '\n') xs in do r <- Data.HashTable.lookup ds x case r of Just b -> spellcheck ds (tail xs') accum _ -> spellcheck ds (tail xs') (x ++ accum) main = do ds <- readFile "Usr.Dict.Words" >>= buildHash hashString hGetContents stdin >>= (\xs -> spellcheck ds xs "") >>= print ---------------------------------------- The Revised program is 33% faster than the Original program using the original dataset. However, if I boost the Input to 1.4M words while keeping the dictionary the same, then the two programs are equal in speed. This suggests that loading the dictionary and building the Hash/Set is faster in the Revised program, but that _lookups_ are _slower_ in the Revised program. Is Hashtable.lookup really slower than Set.elementOf? I'm missing something and I don't know what it is. Frustrating. - Alson

2 1

Kinds in ghc
by Johan Glimming 24 Feb '05

24 Feb '05

Hi I can report success on compiling latest CVS on Mac OS X including stage 2 with ghci support. (greencard does not compile, but that's not a problem for ghc to be compiled it seems.) Now that I have the compiler up, I notice that types are not reported as before. Instead of nice t,t', etc, I get random strings: Kind error: Expecting kind `k_a1JA -> k_a1JE -> k_a1JI -> *', but `DUnit t' has kind `k_a1JA -> k_a1JE -> *' Is this a mere debug mode I have enabled by accident (no parameter passed to make or configure though), or is this something else? P.S. infix type synonyms seems to work well so far! Johan Glimming.

1 0

new ghc under solaris
by Christian Maeder 24 Feb '05

24 Feb '05

Hi Simon and solaris GHC users, I've made progress with ghc HEAD under solaris 8. In fact I could successfully install a ghc-6.5 compiler that was able to compile a couple of files (including "Hello World") But on one file (by chance HughesPJ.hs with an unqualified module name) I got a "Bus Error" (see below) I'll try now if "gmake bootstrap3" fails, too. During "gmake" also the _FILE_OFFSET_BITS warning was not entirely gone: In file included from ../includes/ghcconfig.h:4, from ../includes/Stg.h:42, from ../includes/Rts.h:19, from RetainerSet.c:14: ../includes/ghcautoconf.h:364: warning: `_FILE_OFFSET_BITS' redefined /usr/include/sys/feature_tests.h:96: warning: this is the location of the previous definition. (There were numerous other warnings, too many to post here.) I assume there's not much difference between ghc-6.5 und ghc-6.4 prerelease. Is someone else on the list interested in a solaris distribution and could contribute? Cheers Christian maeder@leo -> ghc -v HughesPJ.hs Glasgow Haskell Compiler, Version 6.5, for Haskell 98, compiled by GHC version 6.2.2 Reading package config file: /home/maeder/leo-ghc-head/lib/ghc-6.5/package.conf Hsc static flags: -static *** Checking old interface for HughesPJ: *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 2602 *** Simplify: Result size = 3233 Result size = 2618 Result size = 2345 Result size = 2345 *** Tidy Core: Result size = 2345 *** CorePrep: Result size = 2877 *** Stg2Stg: *** CodeGen: *** CodeOutput: Bus Error

1 0

Getting ghci to work (Mac OS X & ghc-6.5 from CVS)
by Johan Glimming 23 Feb '05

23 Feb '05

Hi I got ghc-6.5 prerelease from the CVS and managed to get it up and running, *except* for ghci, the interactive part. Is there something in particular that I need to think about to make ghci support get compiled into ghc? Johan Glimming.

2 1

RE: Configuring in directories with spaces fails in ghc6.4
by Simon Marlow 23 Feb '05

23 Feb '05

On 22 February 2005 14:35, Malcolm Wallace wrote: > However, it could be worthwhile halting with an error message. > > case `pwd` in > *' '*) > echo "Error: nhc98 will not build in a directory with spaces > anywhere" echo " in the full pathname." > echo "Suggestion: move the build tree somewhere else." > exit 1 ;; > esac Good idea, done. Simon

1 0

RE: GHC-problem with parsing infix type synonyms - bug?
by Simon Peyton-Jones 23 Feb '05

23 Feb '05

OK, done. I've documented infix classes too. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Johan Glimming | Sent: 17 February 2005 10:04 | To: <glasgow-haskell-users(a)haskell.org> <glasgow-haskell-users(a)haskell.org>; Simon Marlow | Subject: Re: GHC-problem with parsing infix type synonyms - bug? | | > I think the syntax used in your type synonym declaration isn't | > supported | > at the moment. For consistency it probably should be. | | Is there any chance to fix this in the next 6.4 release, or can I patch | 6.4 myself? (I'd need hints though.) I have some code in a project for | which I want to use type synonyms for instead of data type definitions, | to save on all the constructor names hanging around. | | Johan Glimming. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0