- Glasgow-haskell-users

ghc-6.6.1 for FreeBSD/amd64 binary distribution
by Gregory Wright 05 Jun '07

05 Jun '07

Hi, I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 No documentation or ghci. The former might be easily remedied although using FreeBSD's docbook chain, as suggested in the wiki, fails when asked to generate printable docs. The latter seems to be a bigger project since my naive interpretation of the problem is that we need data relocations across a 2GB boundary. The binary works well enough to build itself and darcs. There are only sixteen unexpected test suite failures thus far. I am ignoring these for the moment while I get back to thinking about ghci. Note that you need to install libgmp to use the compiler. libgmp from the ports collection works fine. Best Wishes, Greg

3 4

too much let-floating
by Duncan Coutts 05 Jun '07

05 Jun '07

Hia folks, More performance bugs or misunderstandings. Yes, binary serialisation again. Consider this example from an instance for the Binary serialisation class. We get lots and lots of code that looks like this: data Foo a = Foo Int | Bar ... instance Binary Foo where put (Foo a) = putTag 0 >> put a put (Bar ...) = putTag 1 ... Let's expand this one step so we can see what we want to happen: put (Foo a) = word8 (fromIntegral 0 :: Word8) >> word64le a so we want to combine the bounds checks in word8 and word64le so that we do just one check here rather than two. Lets expand it another step: put (Foo a) = write 1 (pokeWord8 (fromIntegral 0 :: Word8)) `thenPut` write 8 (pokeWord64le (fromIntegral a :: Word64)) Now we have a rule: "write/write" forall n m a b. write n a `thenPut` write m b = write (n+m) (\p -> a p >> b (p `plusPtr` n)) so obviously we'd like to apply this rule here to common-up the bounds check that write n performs. Normally this rule works fine, but in this specific example it does not. Can you spot why? Here's a simple case that works: foo :: Word8 -> Word8 -> Put () foo a b = word8 a >> word8 b and the one that doesn't bar :: Word8 -> Put () bar a = word8 0 >> put a What's the difference? Why should one work and the other not? Of course I gave it away in the email subject: let floating. In the second example, the 'bar' function, word8 0 does not depend on the arguments of the function so it gets floated out: lvl_s198 = write 1 (pokeWord8 0) bar n = thenPut lvl_s198 (write 8 (pokeWord64le n)) and now the rule does not match this because 'write' isn't there directly in the expression. This is a bit disappointing of course, so how do we fix it. There are two possibilities as far as I can see. Either don't let float it, or have the rule matcher look through the indirection. The rule matcher is already looks through lets, but that's a slightly different issue. That's for a situation like: bar n = thenPut (let lvl_s198 = pokeWord8 0 in write 1 lvl_s198) (write 8 (pokeWord64le n)) where we've got an actual let expression whose body would match the rule's pattern. It would not always be a good idea to "look up" let floated vars when doing rule matching since it could lead to duplication. Though in this example the let-floated expression is used only once, so that is not a problem. So one possibility might be to look up variables for the purpose of rule matching if they are only used once. Another possibility might be to not let-float it in the first place. Usually let-floating things like this is a good idea, so how can we spot that we might want to keep it in applicative form? The fact that it's mentioned in the pattern of a rule is the strongest hint. As I understand it, being mentioned in the head of a rule is already taken into account when doing let-floating. However in this case the head of the let-floated expression is not the head of the rule, but a sub expression: write n a `thenPut` write m b = write (n+m) (\p -> a p >> b (p `plusPtr` n)) 'thenPut' is the head of this rule's pattern. But we'd rather not float 'write' out either. So perhaps a similar heuristic should be applied to all the free variables mentioned in the pattern. Another approach might be for the library author to declare that some function is cheap, or is otherwise important to not float out, but should be kept in applicative form to aid rule matching. We have similar problems with list comprehensions and enumFromTo: [ ... | i <- [0..n], j <- [0..m] ] because in the second generator [0..m] does not depend on the first generator, it gets floated out and shared. Of course with fusion we can make the [0..m] extremely cheap, but not if it has been floated out. If it gets floated out and shared in memory between each iteration of the first generator, then we really do have to traverse the list data structure each iteration, rather than just incrementing an unboxed number. So this is another example where we'd like to say that a function, enumFromTo in this case, is extremely cheap and should not be floated out, even if it looses sharing. Actually, my example is simpler because it does not involve any loss of sharing. Duncan

2 3

specialization using RULES
by Scott Dillard 05 Jun '07

05 Jun '07

Hello, This is somewhat related to this thread: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-May/012646.html In that email I asked about the performance of gaussian elimination on small matrices represented by unboxed arrays, because I noticed that unsafeRead was unexpectedly slower than readArray (the cause of this is still unknown.) Mirko Rahn replied with an indexless algorithm where unboxed arrays are replaced by lists-of-lists. http://www.haskell.org/pipermail/glasgow-haskell-users/2007-May/012648.html Besides being infinitely more elegant, I noticed this was considerably faster than my array-based functions, perhaps because of inlining/deforestation/list fusion or some other crazy GHC optimization. So I re-wrote my little affine geometry library representing vectors as lists and matrices as list-of-lists. One thing I wanted this library to do was to enforce dimensionality of the vectors at the type level, so you could not add a two-vector to a three-vector, even though both functions are just "zipWith (+)". After trying to tune my library I came across the SPECIALIZATION/RULES pagmas in the GHC manual, and thought that this phantom dimensionality type would be great for specializing the vector functions, and indeed it speeds things up quite a bit. For instance, if I define > zipWithV :: (Dim d) => (s->s->s) -> Vec d s -> Vec d s -> Vec d s > zipWithV f (Vec u) (Vec v) = Vec( zipWith f u v ) then I can specialize > zipWithV3 :: (s->s->s) -> Vec Three s -> Vec Three s -> Vec Three s > zipWithV3 f (Vec [x,y,z]) (Vec [i,j,k]) = Vec [ f x i, f y j, f k z ] > {-# RULES "zipWith3" zipWithV = zipWithV3 #-} and it makes a nice improvement to the performance of this function. But here comes my problem: Ideally, I should only have to specialize zipWith, map and foldr like this, because everything you could want to do with a vector can be implemented with these functions. (Well, everything I want to do, anyway.) But unfortunately, if I define, say... > instance (Num s) => Num (Vec d s ) where ... (-) = zipWithV (-) > sqrNorm v = sumV ( mapV sqr v ) where sqr x = x*x And I use this as > distance u v = sqrt ( sqrNorm (u-v) ) > doSomethingWith (distance (u :: Vec Three Double) v) The rules do not fire. They only seem to fire if the specialized function is called directly, such as > doSomethingWith ( zipWith (-) (u :: Vec Three Double) v ) I surely do not want to have to specialize all of my vector functions. Just the building blocks. Can anyone shed some light on my situation? Under what conditions do the rules fire? As I understand it, they fire whenever the types are the same. As far as I can tell, this is the case. How can I change things to make the rules fire more often? Thanks, Scott

2 1

2-days old in Haskell
by TOPE KAREM 05 Jun '07

05 Jun '07

I am very new to Haskell, and I am using this webpage as a learning source: http://www.haskell.org/haskellwiki/Haskell_in_5_steps#Install_Haskell I downloaded and instal GHC and it works as was said. I tried to write my first Haskell program: prelude> "Hello World!" "Hello World, World!" it works as said. Then: (This is the problem) I would like to create a source code and compile it using GHC compiler. I opened a notepad and type this program: main = putStrLn "Hello, Word!" I saved this file as hello.hs in the same directory GHCi 6.6.1 was installed. When I tried to compile it as instucted on the webpage ( $ ghc -o hello hello.hs), I got this error message. <interactive>: 1:0: parse error on input '$' please what am I doing wrong. Thank you and sorry for your time. Tope

5 5

GHC Extensibility
by Monique Monteiro 03 Jun '07

03 Jun '07

Hi (this message is mainly intended to the GHC Team), is there any plan to improve GHC's extensibility by providing a simpler way to integrante new backends? I worked at Haskell.NET project in the past, when we integrated successfully a .NET code generator to GHC 6.2.2. As it wasn't stable enough, we didn't integrate it to the main branch. However, I've been trying to integrate our code generator to 6.6.1 and I've not been able to compile it up to now, due to several changes in GHC's code! I haven't yet figured out how to call the .NET code generator from GHC 6.6.1's main function. Further, it would be great if there was a better extensibility mechanism (such as a "plugin" infrastructure, for example) in which it wasn't necessary to use "#ifdef"along the code. Also, it would be very useful if this mechanism/API was well documented. Of course, this is only a suggestion. Best regards. -- __________________________________________________________ Monique Monteiro, MSc MCP .NET Framework 2.0 / SCJP / IBM OOAD Project Manager Recife Microsoft Innovation Center +55 81 34198137 http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx monique(a)qualiti.com.br MSN: monique_louise(a)msn.com

4 9

6.6.1 for windows
by Adrian Hey 01 Jun '07

01 Jun '07

Hello, Can we expect a 6.6.1 binary and/or installer for windows sometime? Thanks -- Adrian Hey

4 3

[slightly OT] ghc-6.6.1 on OpenBSD/i386: internal error (Storage.c)
by Matthias Kilian 31 May '07

31 May '07

Hi, I'm currently working on updating the GHC port to 6.6.1 for OpenBSD, and when I run the testsuite (ghc-regress), all test cases for the way "threaded1", i.e. debug + threaded bail out with an assertion failure: Blocks: 132 live + 123 free = 255 total (508 around) conc010: internal error: ASSERTION FAILED: file Storage.c, line 1174 The numbers vary slightly, but there's always a total of 255 and 508 blocks around, except for one test case (con012), where there are a total of 763 blocks (1016 around). What puzzles me a little bit is the fact that this does *not* happen on amd64 (aka x86_64) but only on i386 so far. So does this ring a bell for anyone? I didn't find anything similar in the archives or in the bug tracker. Ciao, Kili -- CRM114 isn't ugly like PERL. It's a whole different kind of ugly. -- John Bowker

2 3

RE: GHC as a library
by Simon Peyton-Jones 31 May '07

31 May '07

| In typecheckedSource, I can only access the function definitions with | type annotations, but not the data type declaration. | In checkedModuleInfo, I can only access the "Names" of the exported | entities, and but not their (inferred) types are not present. You have easy access to the data decls: In a ModuleInfo is a TypeEnv. The range of the type env (gotten with typeEnvElts) are TyThings. A TyThing can be a Id a Class a TyCon a DataCon So just pull out those TyCons and away you go! (Lots of accessor functions for TyCons in module TyCon.) The Ids are the variables declared in the module, and they each have a type (use idType). In exchange, would you like to document what you have learned? Here for example: http://haskell.org/haskellwiki/GHC/As_a_library Many thanks Simon

2 1

Replacing select() in the non-threaded RTS?
by Bryan O'Sullivan 31 May '07

31 May '07

I notice that select is a bit of a bottleneck in the non-threaded RTS once lots of sockets are in play. Between kernel and userspace, many a cycle are wasted once we go past a few hundred clients. On some operating systems, the fixed nature of fd_set imposes a surprisingly low ceiling on the maximum number of concurrently open file descriptors. I gather there's some kind of longish-term plan to build a more pluggable RTS, but it seems like a nearer-term solution could be implemented relatively cheaply, and wouldn't conflict with the ultimate goal. Would the GHC team be interested in receiving a patch that replaced select, where possible, with an operating system's native, and hopefully faster, event wait mechanism? <b

3 3

GHC.Prim problem
by Ben Sinclair 31 May '07

31 May '07

Hello, I've had a problem with GHC.Prim when compiling the darcs HEAD lately. When I compile it in the normal way with no special options > sh boot && ./configure && make && make install it compiles correctly, but if I attempt to compile > module Main where > > import GHC.Prim > > main :: IO () > main = return () then I get this output: > $ ghc --make Main.hs -fglasgow-exts -v > Glasgow Haskell Compiler, Version 6.7.20070524, for Haskell 98, compiled by GHC version 6.7.20070524 > Using package config file: /usr/local/lib/ghc-6.7.20070524/package.conf > wired-in package base mapped to base-2.1 > wired-in package rts mapped to rts-1.0 > wired-in package haskell98 mapped to haskell98-1.0 > wired-in package template-haskell mapped to template-haskell-0.1 > Hsc static flags: -static > *** Chasing dependencies: > Chasing modules from: Main.hs > Stable obj: [] > Stable BCO: [] > Ready for upsweep > [NONREC > ModSummary { > ms_hs_date = Sat May 26 01:11:06 EST 2007 > ms_mod = main:Main, > ms_imps = [] > ms_srcimps = [] > }] > compile: input file Main.hs > Created temporary directory: /tmp/ghc19188_0 > *** Checking old interface for main:Main: > [1 of 1] Compiling Main ( Main.hs, Main.o ) > *** Parser: > *** Renamer/typechecker: > > Main.hs:3:0: > Failed to load interface for `GHC.Prim': > locations searched: > GHC/Prim.hs > GHC/Prim.lhs > *** Deleting temp files: > Deleting: /tmp/ghc19188_0/ghc19188_0.s > Warning: deleting non-existent /tmp/ghc19188_0/ghc19188_0.s > Upsweep partially successful. > *** Deleting temp files: > Deleting: > link(batch): upsweep (partially) failed OR > Main.main not exported; not linking. > *** Deleting temp files: > Deleting: > *** Deleting temp dirs: > Deleting: /tmp/ghc19188_0 Is there anything I should be doing to make this work? Thanks for any advice, Ben

4 5