May 2009 - Glasgow-haskell-users

Re: haddock-2.3.0 literate comments discarded from .lhs input
by Duncan Coutts 29 May '09

29 May '09

On Wed, 2009-05-27 at 15:10 +0100, Alistair Bayley wrote: > Andrea, > > 2009/3/19 Andrea Vezzosi <sanzhiyan(a)gmail.com>: > > It turns out that those variables are there to allow relocation, in > > fact $topdir is expanded by > > Distribution.Simple.GHC.getInstalledPackages, it seems that > > $httptopdir has been overlooked. > > I'd be tempted to say that it's ghc-pkg dump/describe responsibility > > to expand those vars instead, like it does for ghc-pkg field. > > Do you (or anyone else) intend to work on this? If not, I'd like to > fix it, but I'll need some guidance. Like, is > Distribution.Simple.GHC.getInstalledPackages where the variable > expansion code should go, or should it be somewhere else? I don't think we should be hacking around this in Cabal without any discussion with the ghc folks on what is supposed to be there, what variables are allowed. We need a clear spec on what variables tools are expected to handle and how they are to be interpreted. The output of ghc-pkg describe/dump is not just for ghc to define and play around with. It's supposed to be defined by the Cabal spec. Supporting relocatable sets of packages is a good idea. We should aim to have something that is usable by each compiler, not just ghc, so interpreting paths relative to ghc's libdir doesn't seem ideal. How about this: a way to specify paths in the package registration info that are relative to the location of the package db they are in. That makes sense beyond just ghc and even with would allow other sets of relocatable packages, not just those installed with ghc. Then perhaps as a compat hack we should get Cabal to handle older ghc versions that do use these funny vars. Duncan

2 9

Unqualified names for -ddump-splices?
by Daniel Schüssler 29 May '09

29 May '09

Hi! is it possible to look at spliced code without fully qualified names? (And maybe with simple integer indices for newNames). Currently it can be pretty hard to decipher sometimes :) Greetings, Daniel

2 1

Re: can't run Grapefruit
by Peter Gavin 28 May '09

28 May '09

On Sat, May 23, 2009 at 3:58 PM, Dean Herington <heringtonlacey(a)mindspring.com> wrote: > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> :m + Graphics.UI.Grapefruit.Circuit > Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK > Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + > Examples.Grapefruit.Simple > Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK > Examples.Grapefruit.Simple> run GTK mainCircuit > Loading package syb ... linking ... done. > Loading package base-3.0.3.0 ... linking ... done. > Loading package array-0.2.0.0 ... linking ... done. > Loading package containers-0.2.0.0 ... linking ... done. > Loading package bytestring-0.9.1.4 ... linking ... done. > Loading package old-locale-1.0.0.1 ... linking ... done. > Loading package old-time-1.0.0.1 ... linking ... done. > Loading package random-1.0.0.1 ... linking ... done. > Loading package Win32-2.2.0.0 ... linking ... done. > Loading package filepath-1.1.0.1 ... linking ... done. > Loading package directory-1.0.0.2 ... linking ... done. > Loading package process-1.0.1.0 ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package mtl-1.1.0.2 ... linking ... done. > Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL: could > not load DLL) Hi Dean, First, you should try using the newest version of the installer (0.10.1, it requires GHC 6.10.3). Second, you should check whether intl.dll exists in c:\gtk2hs\0.10.x\bin, and that c:\gtk2hs\0.10.x\bin is also in your PATH. If you're still having problems, please paste the contents of c:\gtk2hs\0.10.x\lib\gtk2hs\{gtk,glib}.package.conf. Please also make sure the libraries listed in the extra-libraries field and extra-ghci-libraries field exist in c:\gtk2hs\0.10.x\lib and c:\gtk2hs\0.10.x\bin respectively. Pete

1 0

Lazy computation being repeated?
by Tyson Whitehead 28 May '09

28 May '09

I have a program that seems to me to be exhibiting strange behaviour. Basically, it looks like something somewhere is not being updated, and this is resulting in (very expensive) computation being repeated. The program in question goes like so. The results from the expensive calculation are stored in this structure data Cache = Cache { cacheBits0 :: UArr Float, cacheBits1 :: UArr Float } and computed by this function (which takes several gigs of RAM) cacheIndex :: ... -> Cache cacheIndex ... = ... The main program is main = catch prog error where prog = do ... let !cache = cacheIndex ... ... run cache ... ... The run function reads an input line from stdin and calls effectChange to performs the indicated calculation run cache ... = loop where loop = do ... case effectChange ... cache of ... ... loop The effectChange function is calculates the change in an auto correlation. It is made much cheaper (order too fast to notice) through the use of a the one time computations stored in cacheBits0 and cacheBits1 (order several seconds). Whether cacheBits1 is used or not depends on the input, while cacheBits0 is always used because I used lengthU cacheBits0 [the fast one from UArr] to get the length of both of them. The first line of input causes a several second delay and lots of memory to be allocated (the cacheBits are being computed). Repeated lines of input respond very quickly and the memory stays mostly constant, unless cacheBits1 is used, in which case there is always a delay of several seconds and big jumps in memory allocation. The only thing I can think of that each time effectsChange is being run and it is uses cacheBits1, it causes it value to be recomputed. Indeed, the delay and big memory jumps go away if I change all references of cacheBits1 to cacheBits0 in effectsChange or make the data fields strict like so data Cache = Cache { cacheBits0 :: !(UArr Float), cacheBits1 :: !(UArr Float) } Does this make sense? Am I missing some reason why this should be the expected behaviour for this program? Thanks! -Tyson

3 2

RE: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types
by Simon Peyton-Jones 28 May '09

28 May '09

You already have splicing for top level decls. Splicing for local decls is a whole different ball game because it brings new *binders* into scope. For example f = ...g... g = let $(foo) in ...f... Is the 'f' inside 'g' the same 'f' as the one bound at top level? Not necessarily, because $(foo) might bind f. So I can't even do dependency analysis to figure out whether f and g are mutually recursive! It gets harder if $(foo) mentions 'f'; and if the definition of 'f' has a declaration splice too. So splicing local decls introduces a new raft of questions whose answers are not obvious, and that might require some substantial structural rearrangement of GHC. In particular to the "rename and then typecheck" strategy. It's very similar to reason that we don't allow splices in patterns. Bottom line: my nose tells me this is a swamp and I'm steering clear of it for now. Simon From: Matt Morrow [mailto:moonpatio@gmail.com] Sent: 28 May 2009 00:08 To: Simon Peyton-Jones Cc: Ross Mellgren; Haskell Cafe; GHC users Subject: Re: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types Spectacular! How difficult would it be to implement splicing in decls? I'm interested in having a go at it, and it seems like a perfect time since I can cheat off the fresh diff. In particular I'd love to be able to do stuff like this (without the current vicious hackery i'm using) (and granted, where i'm splicing is somewhat willy-nilly, but some approximation of this): ----------------------------------------------------------------------------- {-# LANGUAGE TemplateHaskell, QuasiQuotes #-} module DecTest where import HsDec import Data.List import DecTestBoot import Language.Haskell.TH.Lib import Language.Haskell.TH.Syntax import Language.Haskell.Meta.Utils bootQ :: Q [Dec] bootQ = bootQFunct primQStruct primQStruct = (''[] ,(conT ''[] `appT`) ,[|[]|] ,[|null|] ,[|undefined|] ,[|union|] ,[|undefined|] ,[|undefined|]) bootQFunct (primN :: Name ,primQ :: TypeQ -> TypeQ -- exists q. forall a. a -> q a ,emptyQ :: ExpQ -- Q a ,isEmptyQ :: ExpQ -- q a -> Bool ,insertQ :: ExpQ -- Int -> a -> q a -> q a ,mergeQ :: ExpQ -- q a -> q a -> q a ,findMinQ :: ExpQ -- q a -> Maybe (Int, a) ,deleteMinQ :: ExpQ) -- q a -> q a = do n <- newName "a" let primT = varT primN a = varT n [$dec| data BootQ $(a) = Nil | Node {-# UNPACK #-} !Int $(a) ($(primT) (BootQ $(a))) deriving(Eq,Ord) empty :: BootQ $(a) isEmpty :: BootQ $(a) -> Bool insert :: Int -> $(a) -> BootQ $(a) -> BootQ $(a) merge :: BootQ $(a) -> BootQ $(a) -> BootQ $(a) findMin :: BootQ $(a) -> Maybe (Int, $(a)) deleteMin :: BootQ $(a) -> BootQ $(a) empty = Nil isEmpty Nil = True isEmpty _ = False findMin Nil = Nothing findMin (Node n x _) = Just (n, x) insert n x q = merge (Node n x $(emptyQ)) q merge (Node n1 x1 q1) (Node n2 x2 q2) | n1 <= n2 = Node n1 x1 ($(insertQ) n2 (Node n2 x2 q2) q1) | otherwise = Node n2 x2 ($(insertQ) n1 (Node n1 x1 q1) q2) merge Nil q = q merge q Nil = q deleteMin Nil = Nil deleteMin (Node _ _ q) = case $(findMinQ) q of Nothing -> Nil Just (_, Node m y q1) -> let q2 = $(deleteMinQ) q in Node m y ($(mergeQ) q1 q2) |]

1 0

RE: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types
by Simon Peyton-Jones 27 May '09

27 May '09

Folks Quite a few people have asked for splices in Template Haskell *types*, and I have finally gotten around to implementing them. So now you can write things like instance Binary $(blah blah) where ... or f :: $(wubble bubble) -> Int as requested, for example, in the message below. Give it a whirl. You need the HEAD; in a day or two you should find binary snapshots if you don't want to build from source. Simon PS: Note that you (still) cannot write a splice in a *binding* position. Thus you can't write f $(blah blah) = e or data T $(blah blah) = MkT Int I don't intend to change this; see the commentary at http://hackage.haskell.org/trac/ghc/ticket/1476 | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On | Behalf Of Ross Mellgren | Sent: 25 January 2009 19:55 | To: Haskell Cafe | Subject: [Haskell-cafe] Template Haskell very wordy w/r/t Decs and Types | | Hi all, | | I'm writing a small module that exposes a template haskell splice that | takes a (very simplified) C struct definition and builds: | | - A data type definition, | - an instance for Data.Binary.Binary, | - and optionally a pretty print function for it | | However, it seems to do this I have to write a bunch of really ugly | code that builds up the TH data structures "by hand" because quoting | only works with splices for expressions, or so it seems. | | For example, to generate the binary instance I have this code: | | import qualified Language.Haskell.TH as TH | | -- tyname is the name of the data type I've already created, as a | TH.Name | -- tempnames is a list of temporary variable names that are used in | lambda patterns | -- fields is a list of tuples describing each field | -- makeGetExp recursively builds a monadic computation consisting | mostly of Binary.getWord32be >>= \ tempvar -> ... | | binaryInstDec <- liftM (TH.InstanceD [] (TH.AppT (TH.ConT $ | TH.mkName "Data.Binary.Binary") (TH.ConT tyname))) | [d| get = $(makeGetExp (reverse $ zip | fields tempnames) returnExp) | put = undefined |] | | I'd really rather write: | | binaryInstDec <- [d| | instance Binary.Binary $(tyname) where | get = $(makeGetExp (reverse $ zip fields tempnames) | returnExp) | put = undefined |] | | But GHC gives me a syntax error on the tyname splice. The docs seem to | indicate this is the way it is -- that splices in type locations is | plain not implemented. | | My question is whether or not this is just the way it is, and people | writing TH declaration splices tend to have to start manually | assembling a bunch of it, or is there some trick I've missed? Perhaps | even better are there some tricks that people tend to use to make this | less painful? | | I did try using some of the lowercased monadic constructors in | Language.Haskell.TH.Lib but I didn't seem to get anything more succint | out of it.

1 0

Re: mtl and network packages in GHC 6.10.3.*
by Johan Tibell 27 May '09

27 May '09

I'll look into it later today when I have access to a Windows install. On May 27, 2009 3:33 AM, "Neil Mitchell" <ndmitchell(a)gmail.com> wrote: Hi, I just downloaded the Windows snapshot of 6.10.3.20090526, and found that mtl and network don't seem to be included. $ ghc-pkg list c:/ghc/ghc-6.10.3.20090526\package.conf: Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 In addition, I can't install network under Cygwin, Mingw, or the Windows command line. Here are the errors from Cygwin: Preprocessing library network-2.2.1.2... In file included from Network\BSD.hsc:17: include/HsNet.h:78:22: sys/uio.h: No such file or directory include/HsNet.h:81:25: sys/socket.h: No such file or directory include/HsNet.h:84:26: netinet/tcp.h: No such file or directory include/HsNet.h:87:25: netinet/in.h: No such file or directory include/HsNet.h:90:21: sys/un.h: No such file or directory include/HsNet.h:93:24: arpa/inet.h: No such file or directory include/HsNet.h:96:19: netdb.h: No such file or directory In file included from Network\BSD.hsc:17: include/HsNet.h:138: error: syntax error before "addr" include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:146: error: storage size of 'a' isn't known include/HsNet.h:147: error: `addr' undeclared (first use in this function) include/HsNet.h:147: error: (Each undeclared identifier is reported only once include/HsNet.h:147: error: for each function it appears in.) include/HsNet.h:148: warning: return makes pointer from integer without a cast Network\BSD.hsc: In function `main': Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` servent' And Mingw: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal.exe: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: exit: ExitFailure 1 And Windows command line: Resolving dependencies... Configuring network-2.2.1.2... cabal: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: sh: runProcess: does not exist (No such file or directory) Was removal of these packages on the stable branch was an oversight? Could network at the very least be reinstated soon? I'd love to report back whether the GHC 6.10.4 fixes work or not in practice. Thanks Neil _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

runghc failing sometimes on Linux/ppc?
by Jens Petersen 23 May '09

23 May '09

I am seeing some strange failures of runghc on Linux/ppc (Fedora 11 specifically) with ghc-6.10.1 and ghc-6.10.2. For example "cabal install HTTP" works fine but "runghc Setup" failing to run. A workaround (other than using cabal-install) seems to be to compile Setup and then use the output of that to build the package. More strangely this only happens sometimes in the buildsystem, which makes me wonder if it is a fedora issue: most packages built ok in the fedora buildsystem except HTTP and haddock so far. http://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1320158&name=build.log On the other hand in a ppc box I tested on runghc seemed to fail consistently. ghci also segfaulted there. Anyway I thought I would ask here if anyone else had experienced something like this. Jens

2 5

Extensible Exceptions and IO
by Alexander Dunlap 23 May '09

23 May '09

In the extensible exceptions paper[1], which I believe is the guide behind the current Control.Exception in GHC 6.10, a SomeIOException type is discussed so that it would be possible to use the nice interface for IOExceptions. Is this implemented anywhere? In the GHC libraries, all I see is the old interface just plugged into a simple wrapper, so you have to use guard . isDoesNotExistError (for example) with catchJust to catch a certain type of exception. If not, are there any plans to implement it? Alex

2 2

Re: [Haskell-cafe] A problem with par and modules boundaries...
by Duncan Coutts 23 May '09

23 May '09

On Fri, 2009-05-22 at 05:30 -0700, Don Stewart wrote: > Answer recorded at: > > http://haskell.org/haskellwiki/Performance/Parallel I have to complain, this answer doesn't explain anything. This isn't like straight-line performance, there's no reason as far as I can see that inlining should change the operational behaviour of parallel evaluation, unless there's some mistake in the original such as accidentally relying on an unspecified evaluation order. Now, I tried the example using two versions of ghc and I get different behaviour from what other people are seeing. With the original code, (ie parallelize function in the same module) with ghc-6.10.1 I get no speedup at all from -N2 and with 6.11 I get a very good speedup (though single threaded performance is slightly lower in 6.11) Original code ghc-6.10.1, -N1 -N2 real 0m9.435s 0m9.328s user 0m9.369s 0m9.249s ghc-6.11, -N1 -N2 real 0m10.262s 0m6.117s user 0m10.161s 0m11.093s With the parallelize function moved into another module I get no change whatsoever. Indeed even when I force it *not* to be inlined with {-# NOINLINE parallelize #-} then I still get no change in behaviour (as indeed I expected). So I view this advice to force inlining with great suspicion (at worst it encourages people not to think and to look at it as magic). That said, why it does not get any speedup with ghc-6.10 is also a mystery to me (there's very little GC going on). Don: can we change the advice on the wiki please? It currently makes it look like a known and understood issue. If anything we should suggest using a later ghc version. Duncan

2 1