- Glasgow-haskell-users

make html
by Serge D. Mechveliani 01 Jun '05

01 Jun '05

Dear GHC supporters, I have made ghc-6.4 from source by binary itself (Linux, Debian 3.1): cd ghc/6.4/ghc-6.4/ ./configure --prefix=foo make make install But it is so hard to obtain documentation! I tried make html (in the same directory). It reports ------------------------------------------------------------------------ ===fptools== Recursively making `html' in glafp-utils ghc libraries hslibs docs ... PWD = /home/mechvel/ghc/6.4/ghc-6.4 -- ... ... rm -f -rf users_guide/ stringparam base.dir users_guide/ \ --stringparam use.id.as.filename 1 \ --stringparam html.stylesheet fptools.css \ --stringparam toc.section.depth 3 --stringparam section.autolabel 1 --stringparam section.label.includes.component.label 1 \ /html/chunk.xsl users_guide.xml make[3]: stringparam: Command not found ... ************************************************************ The user has managed to make GHC: a big deal. And now has problems with making docs. This looks strange. Why not provide, say, a couple of ready .ps files for user guide and library guide? And if it is .html, let them be ready .html files. ? With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 3

Simplifier output explanation needed
by Jens Fisseler 01 Jun '05

01 Jun '05

Hi everbody! I'm currently trying to optimize some code, in particular trying to make some functions as strict as possible. To do this, I quite often look for strictness annotations either in the interface files or the the simplifier output. Doing this, something odd occured to me: inserting a '$!' into a function call, trying to enforce eager evaluation, the simplifier output changed. Ok, I should expect this, but I don't understand the change. The function name got '$s' as a prefix and the strictness annotation ('Str: DmdType SSL') vanished. So my question is what all those different prefixes mean. I've stumbled across at least '$s' and '$w' (worker wrapper?). Why did the strictness annotation disappear? Is there any documentation that can enlighten me? Regards, Jens

1 0

Re[2]: [Haskell-cafe] ghc 6.4 import problem
by Bulat Ziganshin 31 May '05

31 May '05

Hello Fergus, Tuesday, May 31, 2005, 10:24:41 PM, you wrote: >> import Data.Set hiding (map) >> import qualified Data.Set as Set >> >> will do fine. FH> That code only compiles with ghc 6.4, and won't compile with ghc 6.2: FH> you'll get an error for the "hiding (map)" part, because in 6.2 FH> Data.Set does not contain a "map" function. btw, question to Simon Marlow and Simon PJ - how about disabling this error message? -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

GHC hang
by John Goerzen 31 May '05

31 May '05

Hi, I'm trying to compile WashNGo 2.3.1 on my amd64 machine running GHC 6.4. When compiling HTMLMonad98.hs, ghc hangs. It's been running over 5 minutes now with no output or other activity. What can I do to help the GHC folks debug this?

1 0

RE: Are new sequences really O(1)?
by Simon Marlow 31 May '05

31 May '05

On 27 May 2005 21:02, Marcin 'Qrczak' Kowalczyk wrote: > [moved from libraries to glasgow-haskell-users] > > Ross Paterson <ross(a)soi.city.ac.uk> writes: > >> GCs that happen during this process will be more expensive, as they >> have to scan the stack. I suspect that GC costs are swamping >> everything else for large n. > > I just tweaked the implementation GC in my compiler of my language, > so that minor collection doesn't scan the whole stack, but only the > part up to the deepest point where the stack pointer has been since > the previous collection. Deeper regions contain only old pointers > so they don't need to be scanned (I have only two generations). > > A program which builds a list of length 270,000 non-tail-recursively, > which in a strict language leads to proportional usage of the stack, > and performs on average 4kB of temporary allocations for each element, > so there are 9,000 GCs in total with the young heap of 128 kB, runs 10 > times faster after the change. GC takes 5% of the time instead of 88%. Nice trick. Unfortunately the same assumptions don't hold for GHC's garbage collector - objects are aged in the youngest generation, so it is usually at least two GCs before an object is promoted. We could still do the same trick, but instead we'd have to find maximum stack depth at which all objects below are in an older generation. Incedentally, how do you mark the stack depth? Overwrite a return address with a special one, and keep the real one around in a known place? Cheers, Simon

2 1

explicit signatures and default for integer literals
by Mirko Rahn 31 May '05

31 May '05

Hi all, an explicit given signature causes ghc to choose the right types for integer literals as in {-# OPTIONS -fglasgow-exts #-} import Data.Map f :: Ord a => [a] -> Map a Int f xs = fromList $ zip xs [0..] Here the Literal 0 is threated as (0::Int). But the setting {-# OPTIONS -fglasgow-exts #-} import Data.Map class New a b where new :: a -> b instance Ord a => New [(a,b)] (Map a b) where new = fromList g :: Ord a => [a] -> Map a Int g xs = new $ zip xs [0..] causes the error message Could not deduce (New [(a, b)] (Map a Int)) from the context (Ord a) arising from use of `new' at Why.hs:10:7-9 ghc seems to be unable to threat the Literal 0 as (0::Int) this time but I do not understand why :-( Can anyone explain it? Thanks, -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

6 11

Re: Are new sequences really O(1)?
by Marcin 'Qrczak' Kowalczyk 27 May '05

27 May '05

[moved from libraries to glasgow-haskell-users] Ross Paterson <ross(a)soi.city.ac.uk> writes: > GCs that happen during this process will be more expensive, as they > have to scan the stack. I suspect that GC costs are swamping > everything else for large n. I just tweaked the implementation GC in my compiler of my language, so that minor collection doesn't scan the whole stack, but only the part up to the deepest point where the stack pointer has been since the previous collection. Deeper regions contain only old pointers so they don't need to be scanned (I have only two generations). A program which builds a list of length 270,000 non-tail-recursively, which in a strict language leads to proportional usage of the stack, and performs on average 4kB of temporary allocations for each element, so there are 9,000 GCs in total with the young heap of 128 kB, runs 10 times faster after the change. GC takes 5% of the time instead of 88%. The implementation relies on the fact that only the topmost stack frame can be mutated, so it's enough to look only one frame deeper than the stack pointer reached. Each frame contained a pointer which is used only for GC and for stack trace printing, and thus it can be marked in the lowest bit without impacting normal operations. I prefer to make non-tail recursion efficient than to have to rewrite algorithms to use a large heap instead of the stack. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

1 0

RE: Why hIsEOF wait for completely full buffer while hGetChar doesn't ?
by Simon Marlow 27 May '05

27 May '05

On 27 May 2005 03:33, Nobuo Yamashita wrote: > I am curious about reason why in GHC hIsEOF blocks in BlockBuffering > mode while hGetChar doesn't. > > I wrote following three programs for an experiment. > > -- echo0.hs > module Main where > import System.IO > main = hSetBuffering stdin (BlockBuffering (Just 5)) >> echo > echo = getChar >>= putChar >> hFlush stdout >> echo > > -- echo1.hs > module Main where > import System.IO > main = hSetBuffering stdin (BlockBuffering (Just 5)) >> echo > echo = do eof <- isEOF > if eof then return () > else getChar >>= putChar >> hFlush stdout >> echo > > -- as.hs > module Main where > import System.IO > import Control.Concurrent > main = putChar 'a' >> hFlush stdour >> threadDelay 1000000 >> main > > And run next two commandlines > > % runghc as.hs | runghc echo0.hs > % runghc as.hs | runghc echo1.hs > > I had expected that the both behaviors were same; a character > was output a second. But the former output a character a second, and > the latter output 5 characters a time every 5 seconds. Quite right, that's a bug, or at least an inconsistency. hGetChar used to wait for a completely full buffer before returning a character, but we changed it to return as soon as any data at all was available. However, we didn't change hIsEOF to match: it still waits for a completely full buffer. I've now fixed this. As it turns out, BlockBuffering doesn't really do full block buffering on an input Handle. The BlockBuffering size does specify the maximum amount of buffering performed, but all read operations return as soon as the required amount of data is available, without waiting for the buffer to completely fill up. This seems a lot more useful than strict block buffering. Thanks for a well-researched bug report! Cheers, Simon

1 0

RE: Contexts differ in length
by Simon Peyton-Jones 27 May '05

27 May '05

| A while ago I sent an email to the glasgow haskell users maillinglist to | explain how the "Contexts differ in length" feature (or bug :-)) | restricted me in writing a haskell application. I was hoping for a | reply, however I didn't receive one (yet). It's a sensible suggestion. Until now no one has said it actually stops them writing the program they want to write. Thanks for bringing it up again. It's not too hard to implement, and I'll try to get to it soon. It's in the same patch of the compiler as Ross's specialisation request, so I'll try to do both at once. Simon

3 2

Why hIsEOF wait for completely full buffer while hGetChar doesn't ?
by Nobuo Yamashita 26 May '05

26 May '05

Hello, I am curious about reason why in GHC hIsEOF blocks in BlockBuffering mode while hGetChar doesn't. I wrote following three programs for an experiment. -- echo0.hs module Main where import System.IO main = hSetBuffering stdin (BlockBuffering (Just 5)) >> echo echo = getChar >>= putChar >> hFlush stdout >> echo -- echo1.hs module Main where import System.IO main = hSetBuffering stdin (BlockBuffering (Just 5)) >> echo echo = do eof <- isEOF if eof then return () else getChar >>= putChar >> hFlush stdout >> echo -- as.hs module Main where import System.IO import Control.Concurrent main = putChar 'a' >> hFlush stdour >> threadDelay 1000000 >> main And run next two commandlines % runghc as.hs | runghc echo0.hs % runghc as.hs | runghc echo1.hs I had expected that the both behaviors were same; a character was output a second. But the former output a character a second, and the latter output 5 characters a time every 5 seconds. Are there any explanations ? Best regards. -- Nobuo Yamashita

1 0