From rl at cse.unsw.edu.au Sun Mar 1 00:31:50 2009 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sun Mar 1 00:20:49 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <20090228174932.GA23519@whirlpool.galois.com> References: <20090228174932.GA23519@whirlpool.galois.com> Message-ID: On 01/03/2009, at 04:49, Don Stewart wrote: > So now, since we've gone to such effort to produce a tiny loop like, > this, > can't we unroll it just a little? Sadly, my attempts to get GCC to > trigger > its loop unroller on this guy haven't succeeded. -funroll-loops and > -funroll-all-loops doesn't touch it, That's because the C produced by GHC doesn't look like a loop to GCC. This can be fixed but given that we are moving away from -fvia-C anyway, it probably isn't worth doing. > Anyone think of a way to apply Claus' TH unroller, or somehow > convince GCC > it is worth unrolling this guy, so we get the win of both aggressive > high level > fusion, and aggressive low level loop optimisations? The problem with low-level loop optimisations is that in general, they should be done at a low level. Core is much too early for this. To find out whether and how much to unroll a particular loop, you must take things like register pressure and instruction scheduling into account. IMO, the backend is the only reasonable place to do these optimisations. Using an exisiting backend like LLVM would really help here. Roman From claus.reinke at talk21.com Sun Mar 1 07:55:28 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Mar 1 07:44:19 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com> Message-ID: >> its loop unroller on this guy haven't succeeded. -funroll-loops and >> -funroll-all-loops doesn't touch it, > > That's because the C produced by GHC doesn't look like a loop to GCC. This can be fixed but given > that we are moving away from -fvia-C anyway, it probably isn't worth doing. That was one of my questions in the optimization and rewrite rules thread: shouldn't -fvia-C be supported (as a non-default option) for at least as long as the alternative isn't a clear win in all cases? If there are small changes that could make GHC-generated code more palatable to GCC's optimizer, wouldn't that be worth doing? Once -fvia-C is allowed to bitrot to the level of unoptimized bootstraps only, we might never get the good performance route back, so why not keep it in good shape as long as it offers real benefits? > The problem with low-level loop optimisations is that in general, they should be done at a low > level. Core is much too early for this. To find out whether and how much to unroll a particular > loop, you must take things like register pressure and instruction scheduling into account. IMO, > the backend is the only reasonable place to do these optimisations. [1] is one example reference for this argument (late unrolling). And since most compiler textbooks are oddly quiet about optimizations and their interactions, the survey [2] might also be helpful (and [3] has some pointers to more recent work). However, I'd like to note that Core is rather different from conventional language source-level code, so I would expect benefits from source-level "unrolling", too: Core retains much more of the high-level semantics, so both identifying loops and applying library-specific optimizations after unrolling are much easier here than at the basic block level in the backend. After all, it is just the normal unfolding/inlining that forms the starting point for so many of GHC's optimizations, which just happens to be blind to recursive definitions at the moment. Recursive definitions are quite widely used in Haskell code, so this blindspot can't be good for the overall effectiveness of GHC's optimizer. If one could mark recursive bindings with a counter, to limit unfoldings according to a compiler option, generalised loop unrolling would just be a consequence of what GHC does anyway, right? That doesn't change the point that, at the lower level, loop unrolling interacts strongly with the target architecture, and that some relevant information is not available at Core level. But it might be better to do both Core-level unfolding (to enable further Core2Core optimizations, independent of platform, that might no longer be visible at backend level) and backend-level unfolding and re-folding (to massage the low-level flow graph into a shape suited for the target architecture, about which the Core level has no information). One might also expect that Core-level transformations are affected by compiler flags which users select according to their target architecture (common practice at the moment), so Core2Core isn't entirely out of that loop, either;-) It is worth noting that there is a third level of optimizations, even after the backend, in modern hardware, as these notes [4] for an Intel compiler's unrolling option document. And since I'm collecting references, there's also Ian's TH [5] for doing the unrolling even before Core. Claus [1] An Aggressive Approach to Loop Unrolling, 1995 http://citeseer.ist.psu.edu/old/620489.html [2] Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.4885 [3] http://en.wikipedia.org/wiki/Loop_transformation [4] http://www.intel.com/software/products/compilers/flin/docs/main_for/mergedprojects/optaps_for/common/optaps_hlo_unrl.htm [5] Unrolling and simplifying expressions with Template Haskell, Ian Lynagh, 2003 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.9813 From phercek at gmail.com Sun Mar 1 08:00:08 2009 From: phercek at gmail.com (Peter Hercek) Date: Sun Mar 1 07:51:16 2009 Subject: how dynamic stack approximation works In-Reply-To: <20090224104932.088890dc.Malcolm.Wallace@cs.york.ac.uk> References: <498C60A9.1030409@gmail.com> <49908120.2040005@gmail.com> <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> <499A794F.3020108@gmail.com> <20090224104932.088890dc.Malcolm.Wallace@cs.york.ac.uk> Message-ID: Malcolm Wallace wrote: > In a lazy language, the dynamic stack rarely tells you anything of > interest for debugging. For the value at the top of the stack, you get > one of many possible _demand_ chains, rather than the creation chain. > The demanding location is pretty-much guaranteed not to be the site of > the bug. > > But you can think of the lexical call stack as what _would_ have been > the dynamic call stack, if only the language were completely strict > rather than lazy. Most people find the latter notion more intuitive for > the purposes of finding program errors. OK, maybe I understand it. If the lexical stack would give me access to local variables for all its frames it would be probably better. In the current situation where I have only access to the free vars in the current expression it is not that useful. I mean for my code I know what is the creation chain. This may be different if I would debug somebody else's code. But when debugging my code I sometimes lose track what demand chain I'm in or why the hell I'm at the given location at all. Dynamic stack would help here a lot and it would help me to better understand lazy behavior of my code. The creation behavior is rather clear to me because it is explicit in the code. The lazy behavior may be more tough because it is implicit. >> Sure, but the plan to maintain an approximate debugging dynamic stack >> depends on one thing: > > There is no need to approximate the dynamic stack. It is directly > available to the RTS, in full detail. Well, but this would be the exact stack. It would be great to see how ghci works but I'm not sure how much helpful it would be for debugging. I'm afraid it would have the same problem as _return binding (bug #1531). In my code _return is mostly wrong. I'm not even checking it out any more. Thanks, Peter. From claus.reinke at talk21.com Sun Mar 1 08:50:40 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Mar 1 08:39:31 2009 Subject: Int vs Word performance? References: <2F82FE4EB64E4D4FB511B9BB82B6C8F6@cr3lt><20090227002825.GH15172@whirlpool.galois.com><4BB1F2BA9DBE45CB8DF3DD4C45247D55@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C33399741900@EA-EXMSG-C334.europe.corp.microsoft.com> <638ABD0A29C8884A91BC5FB5C349B1C33399741905@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <19481C0AF0AC48199C29D8E013125FD4@cr3lt> | | A quick grep shows almost no specialization at all for Word, or for | | IntXX/WordXX (see below). Still, none of that seems to explain the | | example repeated at the top of this message. | | We'd be delighted to apply suitable library patches. >PS: in the case that no one gets around to creating such a patch, >creating a ticket that documents the problem and points to the >needed specialisations would be a start Since more that just SPECIALI[SZ]E pragmas seem involved, I've created a ticket to summarize this thread's findings: http://hackage.haskell.org/trac/ghc/ticket/3055 Claus From phercek at gmail.com Sun Mar 1 09:09:53 2009 From: phercek at gmail.com (Peter Hercek) Date: Sun Mar 1 09:01:01 2009 Subject: how dynamic stack approximation works In-Reply-To: <49A3F6CC.4060008@gmail.com> References: <498C60A9.1030409@gmail.com> <49908120.2040005@gmail.com> <3929D22A-D99F-4511-B80D-F61D60CACDC8@gmail.com> <499A794F.3020108@gmail.com> <49A3F6CC.4060008@gmail.com> Message-ID: Simon Marlow wrote: > Peter Hercek wrote: >> Sure, but the plan to maintain an approximate debugging dynamic stack >> depends on one thing: >> The number of items (continuations) on the return stack from the >> beginning of /case tick of {_->e}/ to the moment when we can check >> the count of items in the return stack inside /tick/ is constant >> and known for a given runtime version of ghc. Or variable but known >> for each call individually. This is important to find out the number >> of return addresses on the return stack just before the execution of >> /case tick of {_->e}/. > > I don't fully understand what it is you mean. e.g. I don't know what > "from the beginning of /case tick of {_->e}/" means. > > Let me try to explain a couple of things that might (or might not!) help > clarify. We don't normally see > > case tick of { _ -> e } > > because the byte-code generator turns this into > > let > z = case tick of { _ -> e } > in > z > > the debugger paper explains why we do this. Anyway, the byte code for > the closure for z does this: > > - if the breakpoint at is enabled then stop, > - otherwise, evaluate e > > i.e. it doesn't push any stack frames. > > Does that help frame your question? I reread the paper and together with this it actually answered my question. I thought that tick represents a call to the debugger. But it is only a byte code which is checked by interpreter and if the debugging location is enabled then the interpreter breaks. Also I have found out that what I originally intended would not work because the interpreter can beak only at the beginning of a BCO. But maybe there are other almost as good solutions. I'm aiming at these features: * :next command with the meaning: Break at the next source span which has the same or smaller number of addresses on the return stack and which is not a subset of the current source span. * :stepout command with the meaning: Break at the next source span which has smaller number of addresses on the return stack. * build dynamic stack (more or less entirely in GHCi so if it is not used it should not slow down GHC code interpretation; well doing it in GHCi would mean it would be painfully slow because of thread switches but if it proves useful it can be moved to GHC) * ... and maybe also something like the last one (or the last few) frames of lexical stack for the current source span; this one may not be even that interesting if options to filter trace log are fine enough; the problem with trace log is anything which is executed in a loop (so e.g. even some stupid lambda in a map cal) I'm not aiming at full lexical stack. This is not a promise I'll implement the above things. I would like just some more information: * what would be a good way (if any) to implement a new kind of break point: Break at any tick (source span) if number of addresses on the return stack is less than given number. Actually the ability to count number of return addresses (although useful) is not that important. It is important to find out whether the current return stack has more, less, or the same number of return adresses than it had in a given moment in past. Any good paper / web page where I could find how the return stack is actually implemented? * any good paper / web page where I can find how GHC profiler derives lexical call stack approximation? Thanks, Peter. From phercek at gmail.com Sun Mar 1 11:04:33 2009 From: phercek at gmail.com (Peter Hercek) Date: Sun Mar 1 10:55:43 2009 Subject: a possibility to redefine built-in GHCi commands Message-ID: Hi GHCi users, I would like to be able to redefine the built-in GHCi commands. The idea is that when searching for a command the user defined commands would be searched first and only then the built-in commands would be searched. If user wants to invoke a built-in command regardless of user defined commands he/she would need to start it with two colons (instead of one). It is an user interface change which may break some scripts, but it would allow to provide different default behavior. For example: * when I use GhciExt I want all my ":continue" commands to be actually ":x :continue" * it would allow to specify different order of searching for abbreviated commands as the default one * it would allow to specify different default switches for builtin commands Would such a change be merged upstream if I would provide a patch? Peter. From claus.reinke at talk21.com Sun Mar 1 11:42:27 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Mar 1 11:31:17 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com> Message-ID: <26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> > So now, since we've gone to such effort to produce a tiny loop like, this, > can't we unroll it just a little? > it is worth unrolling this guy, so we get the win of both aggressive high level > fusion, and aggressive low level loop optimisations? It might be useful to point out that the interaction goes both ways. Not only are fused loops candidates for unrolling, but unrolling can also enable fusion, giving one example of why Core-level unrolling (in addition to backend-level loop restructuring) would be useful. Consider this silly example (with Apply as before, in the rewrite rules thread, just syntactically unrolling the loop, and loop as before, but generalised to arbitrary accumulators, see below): -------------------------------------------------------- {-# LANGUAGE MagicHash #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE BangPatterns #-} import Data.Array.Vector import Data.Bits import Apply import GHC.Prim import GHC.Base main = print $ loop 1 10000000 body (toU [1,2,3,4,5::Int]) body i arr = mapU (42+) arr -------------------------------------------------------- Here, the refusal to partially unfold recursive definitions means there are no opportunities for fusion, whereas unrolling enables fusion (which wouldn't work if unrolling was done only in the backend, after fusion). -------------------------------------------------------- {-# INLINE loop #-} loop :: Int -> Int -> (Int -> acc -> acc) -> acc -> acc loop i max body acc = loopW i acc where #ifdef N loopW !i !acc | i+N<=max = loopW (i+N) ($(apply (0::Int) N) (\j acc->body (i+j) acc) acc) #endif loopW !i !acc | i<=max = loopW (i+1) (body i acc) | otherwise = acc -------------------------------------------------------- Compare the versions without and with unrolling, not just for time, but for allocation (+RTS -s). As usual, we'd like to reassociate the sums to enable constant folding, but this rule {-# RULES -- "reassoc" forall a# b# c. ((I# a#) +# ((I# b#) +# c)) = ((I# a#) +# (I# b#)) +# c #-} is rejected. Claus From batterseapower at hotmail.com Sun Mar 1 12:32:28 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sun Mar 1 12:21:14 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> References: <20090228174932.GA23519@whirlpool.galois.com> <26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> Message-ID: <9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com> 2009/3/1 Claus Reinke : > It might be useful to point out that the interaction goes both ways. > Not only are fused loops candidates for unrolling, but unrolling > can also enable fusion, giving one example of why Core-level > unrolling (in addition to backend-level loop restructuring) would > be useful. Yes - this is why my use of a kind of unrolling fixes concatMap for streams, because GHC is able to specialise the "unrolled" function body on a particular lambda abstraction. However, this is really a somewhat seperate issue than plain unrolling, as we just want to be able to /specialise/ recursive functions on particular arguments rather than reduce loop overhead / reassociate arithmetic over several iterations. This is why the static argument transformation is such a big win (as I've mentioned before, 12% decrease in nofib runtime if you use it) - because it finds instances of recursive definitions where it's a REALLY GOOD idea to specialise on a particular argument (since that argument is actually /invariant/) and gives GHC the opportunity to specialise on it by creating a nonrecursive wrapper around the recursive worker loop. In general, the compiler wants to be able to determine the structure of the argument of a loop body in a more fine grained way than just "invariant vs non-invariant" as SAT does. A particularly tempting example of an optimisation you could do if we dealt with recursive functions better is strength reduction. This is part of what I'm looking at implementing for GHC currently. Cheers, Max From claus.reinke at talk21.com Sun Mar 1 16:17:00 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Mar 1 16:05:51 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> <9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com> Message-ID: <35DD9685B0814863B1379F2995C81F8C@cr3lt> > Yes - this is why my use of a kind of unrolling fixes concatMap for > streams, because GHC is able to specialise the "unrolled" function > body on a particular lambda abstraction. However, this is really a > somewhat seperate issue than plain unrolling, as we just want to be > able to /specialise/ recursive functions on particular arguments > rather than reduce loop overhead / reassociate arithmetic over several > iterations. What is the issue with concatMap? It sounds like your specialization is based on the recursion equivalent to loop peeling (unrolling the "non-recursive" calls, the entry points into the recursion), a close variant of loop unrolling (unrolling the recursive calls, inside the loop body). If followed by the static argument transformation, that might cover the majority of hand-written worker-wrapper pairs (replacing manual by compiler optimization is always nice). So, instead of splitting recursive 'f' into 'fWorker' and 'fWrapper', with an INLINE pragma for 'fWrapper', one might in future be able just to say '{-# INLINE f PEEL 1 UNROLL 0 #-}' or, if unrolling is also desirable '{-# INLINE f PEEL 1 UNROLL 8 #-}'? And GHC would do the work, by unfolding the entry points once (the inlining of the wrapper), unfolding the recursive calls 8 times (the loop unrolling), and taking the INLINE PEEL pragma also as a hint to try the static argument transformation. > This is why the static argument transformation is such a big win (as > I've mentioned before, 12% decrease in nofib runtime if you use it) - > because it finds instances of recursive definitions where it's a > REALLY GOOD idea to specialise on a particular argument (since that > argument is actually /invariant/) and gives GHC the opportunity to > specialise on it by creating a nonrecursive wrapper around the > recursive worker loop. > > In general, the compiler wants to be able to determine the structure > of the argument of a loop body in a more fine grained way than just > "invariant vs non-invariant" as SAT does. A particularly tempting > example of an optimisation you could do if we dealt with recursive > functions better is strength reduction. This is part of what I'm > looking at implementing for GHC currently. It seems that strength reduction could be seen as loop restructuring in the small: a multiplication, if seen as a repeated addition, can be unrolled, or the implicit adding loop can be fused with the explicit loop in which multiplication is called on (eg figure 7 in the ACM survey paper I mentioned). That way, no separate framework would be needed for strength reduction. Btw, is that also what happened in the -fvia-C path of Don's initial example in this thread (I don't know how to read those leaqs, but the imulq is gone)? But all these follow-on optimizations enabled by unfolding recursive definitions seem to require further thought and design, whereas user-controlled recursion unfolding (both peel and unroll) seems to offer immediate benefits. Is that part of your current work? Do you forsee any problems with the implementation, or with the API I suggested above (adding PEEL and UNROLL options to INLINE pragmas, to make them effective on recursive definitions as well)? Claus From batterseapower at hotmail.com Sun Mar 1 17:31:13 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sun Mar 1 17:19:59 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <35DD9685B0814863B1379F2995C81F8C@cr3lt> References: <20090228174932.GA23519@whirlpool.galois.com> <26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> <9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com> <35DD9685B0814863B1379F2995C81F8C@cr3lt> Message-ID: <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> 2009/3/1 Claus Reinke : > What is the issue with concatMap? ConcatMap doesn't usually fuse under stream fusion - see http://www.cse.unsw.edu.au/~dons/papers/stream-fusion.pdf for the gory details. > It sounds like your specialization > is based on the recursion equivalent to loop peeling (unrolling the > "non-recursive" calls, the entry points into the recursion), a close variant > of loop unrolling (unrolling the recursive calls, inside the loop > body). This sounds right - to get concatMap specialised I "unpeel" the unstream loop (which has been slightly modified) 4 iterations, after which unstream recurses back into itself in a tight loop. This lets GHC specialise the first 3 iterations however it likes. This is achieved by the spec4 combinator in the code I posted. > If followed by the static argument transformation, that might cover > the majority of hand-written worker-wrapper pairs (replacing manual by > compiler optimization is always nice). Right. Since GHC is so blind to recursion at the moment this could be a substantial win (though my gut tells me that SAT alone is a large part of the win here). > So, instead of splitting recursive 'f' into 'fWorker' and 'fWrapper', with > an INLINE pragma for 'fWrapper', one might in future be able just to say > '{-# INLINE f PEEL 1 UNROLL 0 #-}' or, if unrolling > is also desirable '{-# INLINE f PEEL 1 UNROLL 8 #-}'? And GHC would do the > work, by unfolding the entry points once (the > inlining of the wrapper), unfolding the recursive calls 8 times (the > loop unrolling), and taking the INLINE PEEL pragma also as a hint to try the > static argument transformation. Right, and INLINE PEEL might be a nice interface for the user. Of course, we'd probably want an automated system for working out when this is a good idea as well - in the same way that we have INLINE pragmas and a load of inlining heuristics. > It seems that strength reduction could be seen as loop restructuring > in the small: a multiplication, if seen as a repeated addition, can be > unrolled, or the implicit adding loop can be fused with the explicit loop in > which multiplication is called on (eg figure 7 in the ACM survey paper I > mentioned). I hadn't thought about it in quite those terms before - cute :-) > That way, no separate framework > would be needed for strength reduction. Btw, is that also what happened in > the -fvia-C path of Don's initial example in this thread (I don't know how > to read those leaqs, but the imulq is gone)? I am no assembly guru and haven't seen that last form of leaq either, but I'm going to guess that: leaq (%rsi,%rsi,4), %rax Says that rax is rsi * ((1 + 1) * 2 ^ 4) = rsi * 32 leaq 0(,%rax,8), %rsi And that this finishes it off by adding the final 8* to the mix. So it makes the multiplication easier by breaking it into two multiplications by powers of two. Smart, but you don't need any loop unrolling tech to do it. > But all these follow-on optimizations enabled by unfolding recursive > definitions seem to require further thought and design, whereas > user-controlled recursion unfolding (both peel and unroll) seems > to offer immediate benefits. Is that part of your current work? I hadn't actually considered a mechanism user-controlled peel/unroll at all! I was totally focused on automatic transformations :-) > Do you forsee any problems with the implementation, or with > the API I suggested above (adding PEEL and UNROLL options > to INLINE pragmas, to make them effective on recursive > definitions as well)? The implementation I'm thinking of is basically trivial. You just add the information gathered from the pragmas onto the Ids, then have a dedicated core pass that looks at the pragmas and does it's worker/wrapper thing. The technology to do peeling/unrolling is trivial and there already examples in the codebase (in case liberation and SAT). If someone can spec out what they actually want and GHC HQ give it the thumbs up I would be happy to do the grunt work on implementing this feature. I'm not so sure about the user interface - for the purposes of compatibility with other compiler's notion of INLINE perhaps a dedicated PEEL / UNROLL pragma is a good idea. This would be less painful if we had a positional notation for pragmas - which has been mooted in the past wrt. the annotation system for compiler plugins (which IS in HEAD). AFAIK the only reason we don't have this is that we haven't had a discussion about how it should look. See "Future work" on the page http://hackage.haskell.org/trac/ghc/wiki/Annotations Incidentally, Simon PJ has just made GHC warn about INLINE pragmas on recursive things (not something I totally sure is a good idea, since the compiler can make things non-recursive behind your back) but which you can justify by saying that /normally/ GHC won't INLINE recursive things, so it's misleading to have INLINE pragmas on them accepted. This can be taken as an argument against adding PEEL / UNROLL to INLINE. Cheers, Max From twhitehead at gmail.com Mon Mar 2 14:42:33 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Mar 2 14:31:42 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> References: <20090228174932.GA23519@whirlpool.galois.com> <35DD9685B0814863B1379F2995C81F8C@cr3lt> <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> Message-ID: <200903021442.49757.twhitehead@gmail.com> On March 1, 2009 17:31:13 Max Bolingbroke wrote: > I am no assembly guru and haven't seen that last form of leaq either, > but I'm going to guess that: > > leaq (%rsi,%rsi,4), %rax > > Says that rax is rsi * ((1 + 1) * 2 ^ 4) = rsi * 32 > > leaq 0(,%rax,8), %rsi If I recall correctly, leaq is load effective address (i.e., write the address into the destination register instead of the data at the address). The address form is i(b,o,s) = i+b+o*s. You have (%rsi,%rsi,4) = %rsi+%rsi*4 into %rax followed by 0(,%rax,8) = rax*8 into %rsi, ultimately giving %rsi*40 into %rsi (which is the multiplication you have in the ghc generated loop). (the restrictions on the address form is that s must be one of 1, 2, 4, or 8) Interesting discussion by the way. : ) Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090302/82fd7cbf/attachment.bin From dan.doel at gmail.com Thu Mar 5 22:07:39 2009 From: dan.doel at gmail.com (Dan Doel) Date: Thu Mar 5 21:56:13 2009 Subject: Deep fmap with GADTs and type families. Message-ID: <200903052207.40062.dan.doel@gmail.com> Greetings, Someone on comp.lang.functional was asking how to map through arbitrary nestings of lists, so I thought I'd demonstrate how his non-working ML function could actually be typed in GHC, like so: --- snip --- {-# LANGUAGE TypeFamilies, GADTs, EmptyDataDecls, Rank2Types, ScopedTypeVariables #-} data Z data S n data Nat n where Z :: Nat Z S :: Nat n -> Nat (S n) type family Nest n (f :: * -> *) a :: * type instance Nest Z f a = f a type instance Nest (S n) f a = f (Nest n f a) deepMap :: Nat n -> (a -> b) -> Nest n [] a -> Nest n [] b deepMap Z f = map f deepMap (S n) f = map (deepMap n f) --- snip --- This works. However, the straight forward generalisation doesn't: --- snip --- deepFMap :: Functor f => Nat n -> (a -> b) -> Nest n f a -> Nest n f b deepFMap Z f = fmap f deepFMap (S n) f = fmap (deepFMap n f) --- snip --- This fails with a couple errors like: Map.hs:25:19: Couldn't match expected type `Nest n1 f b' against inferred type `Nest n1 f1 b' In the expression: fmap (deepFMap n f) In the definition of `deepFMap': deepFMap (S n) f = fmap (deepFMap n f) for reasons I don't really understand. So I tried the following: --- snip --- newtype FuntorD f = F { fdmap :: forall a b. (a -> b) -> f a -> f b } deepFDMap :: FunctorD f -> Nat n -> (a -> b) -> Nest n f a -> Nest n f b deepFDMap d Z f = fdmap d f deepFDMap d (S n) f = fdmap d (deepFDMap d n f) --- snip --- This works, but to my surprise "deepFMap = deepFDMap (F fmap)" gives the exact same error as above. Bringing my situation to #haskell, two solutions were found: --- snip --- deepFMap :: forall n f a b. Functor f => Nat n -> (a -> b) -> Nest n f a -> Nest n f b deepFMap = deepFDMap (F fmap :: FunctorD f) data Proxy (f :: * -> *) = Proxy deepFMap' :: Functor f => Proxy f -> Nat n -> (a -> b) -> Nest n f a -> Nest n f b deepFMap' _ Z f = fmap f deepFMap' p (S n) f = fmap (deepFMap p n f) --- snip --- But we've so far not been able to find a way of merely annotating the original into working. So, I was wondering if any of the more knowledgeable folks here could illuminate what's going wrong here, and whether I should expect my original code to work or not. Thanks in advance. -- Dan From dave at zednenem.com Thu Mar 5 23:25:21 2009 From: dave at zednenem.com (David Menendez) Date: Thu Mar 5 23:13:56 2009 Subject: Deep fmap with GADTs and type families. In-Reply-To: <200903052207.40062.dan.doel@gmail.com> References: <200903052207.40062.dan.doel@gmail.com> Message-ID: <49a77b7a0903052025v4268a0bjc96009d8b5e7115b@mail.gmail.com> On Thu, Mar 5, 2009 at 10:07 PM, Dan Doel wrote: > > But we've so far not been able to find a way of merely annotating the original > into working. So, I was wondering if any of the more knowledgeable folks here > could illuminate what's going wrong here, and whether I should expect my > original code to work or not. I'll bet the problem has to do with the fact that "f" only appears in "Nest n f a", so the type checker can't figure out what "f" is. Here are two other variants that work. deepFMap :: Functor f => Nat n -> (a -> b) -> Nest n f a -> Nest n f b deepFMap Z f = fmap f deepFMap (S n) f = deepFMapS n f deepFMapS :: Functor f => Nat n -> (a -> b) -> f (Nest n f a) -> f (Nest n f b) deepFMapS Z f = fmap (fmap f) deepFMapS (S n) f = fmap (deepFMapS n f) -- alternative: -- deepFMapS (S n) f = fmap (deepFMap (S n) f) type family Nest' n (f :: * -> *) a :: * type instance Nest' Z f a = a type instance Nest' (S n) f a = f (Nest' n f a) deepFMap' :: Functor f => Nat n -> (a -> b) -> f (Nest' n f a) -> f (Nest' n f b) deepFMap' Z f = fmap f deepFMap' (S n) f = fmap (deepFMap' n f) -- Dave Menendez From chak at cse.unsw.edu.au Fri Mar 6 00:11:17 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Mar 5 23:59:54 2009 Subject: Deep fmap with GADTs and type families. In-Reply-To: <49a77b7a0903052025v4268a0bjc96009d8b5e7115b@mail.gmail.com> References: <200903052207.40062.dan.doel@gmail.com> <49a77b7a0903052025v4268a0bjc96009d8b5e7115b@mail.gmail.com> Message-ID: <3545121C-F1F5-49C8-9125-F3A03F3D759B@cse.unsw.edu.au> David Menendez: > On Thu, Mar 5, 2009 at 10:07 PM, Dan Doel wrote: >> >> But we've so far not been able to find a way of merely annotating >> the original >> into working. So, I was wondering if any of the more knowledgeable >> folks here >> could illuminate what's going wrong here, and whether I should >> expect my >> original code to work or not. > > I'll bet the problem has to do with the fact that "f" only appears in > "Nest n f a", so the type checker can't figure out what "f" is. Exactly. In other words, the signature is ambiguous. Manuel From marlowsd at gmail.com Fri Mar 6 08:57:25 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Mar 6 08:46:04 2009 Subject: Loop unrolling + fusion ? In-Reply-To: References: <20090228174932.GA23519@whirlpool.galois.com> Message-ID: <49B12BC5.8090008@gmail.com> Claus Reinke wrote: >>> its loop unroller on this guy haven't succeeded. -funroll-loops and >>> -funroll-all-loops doesn't touch it, >> >> That's because the C produced by GHC doesn't look like a loop to GCC. >> This can be fixed but given that we are moving away from -fvia-C >> anyway, it probably isn't worth doing. > > That was one of my questions in the optimization and rewrite rules > thread: shouldn't -fvia-C be supported (as a non-default option) > for at least as long as the alternative isn't a clear win in all cases? > > If there are small changes that could make GHC-generated code > more palatable to GCC's optimizer, wouldn't that be worth doing? > Once -fvia-C is allowed to bitrot to the level of unoptimized > bootstraps only, we might never get the good performance route > back, so why not keep it in good shape as long as it offers real benefits? The trouble with supporting multiple backends is that the cost in terms of testing and maintenance is high. And the registerised -fvia-C backend is particularly nasty, coming as it does with thousands of lines of Perl 4 that regularly get broken by new versions of gcc. The registerised via-C backend should have been retired long ago. It's time to take it round back and shoot it. We should spend our efforts on finding a good long-term solution rather than patching this dead-end, IMHO. Cheers, Simon From igloo at earth.li Fri Mar 6 14:28:07 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Mar 6 14:16:38 2009 Subject: Warning about unrecognised pragma In-Reply-To: References: Message-ID: <20090306192807.GA29866@matrix.chaos.earth.li> Hi Colin, On Thu, Feb 05, 2009 at 11:27:05AM +0000, Colin Paul Adams wrote: > I am getting messages: > > Board_representation.hs:407:0: Unrecognised pragma > > Board_representation.hs:442:0: Unrecognised pragma > > Board_representation.hs:458:0: Unrecognised pragma > > I looked into the documentation to see how to supress these warnings > (prefereably for the particular pragma concerned), but I found (from 8.13): > > any pragma encountered with an unrecognised word is (silently) ignored. I've fixed the documentation now, but can I ask what pragmas these are? If they're something common then we should teach GHC to ignore them. Thanks Ian From claus.reinke at talk21.com Fri Mar 6 16:28:10 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Mar 6 16:16:46 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com> <49B12BC5.8090008@gmail.com> Message-ID: >> That was one of my questions in the optimization and rewrite rules >> thread: shouldn't -fvia-C be supported (as a non-default option) >> for at least as long as the alternative isn't a clear win in all cases? > > The trouble with supporting multiple backends is that the cost in terms of > testing and maintenance is high. And the registerised -fvia-C backend is > particularly nasty, coming as it does with thousands of lines of Perl 4 > that regularly get broken by new versions of gcc. Yes, I can understand that you'd like to leave that part behind sometime before yesterday:-) I assume that this very complexity means that the -fvia-C route doesn't really get all the way to its most interesting promises (easy portability, and full backend optimizations inherited from gcc). And with that in mind, I can also understand that you don't want to put in any further work into trying to improve it, if that distracts from a better long-term solution. What I don't understand yet is the routemap for replacing -fvia-C. We've seen -fvia-C being demoted from default to backup (fine by me), we've seen a feature supported only by -fvia-C removed completely, instead of seeing support for it added to the -fasm route (macro-based APIs used to work with ffi, would now require a wrapper generator, which doesn't exist yet). Indications are that -fvia-C still tends to produce better code (even though it is not the best that ghc+gcc could produce) than -fasm (is that any better for the new backend?). And last, but not least, ghc has more limited resources than gcc, so how is ghc going to beat gcc at the portability and backend optimizations game while still making progress in its core competencies (ie, higher-level improvements; there's also the interesting side-issue of how the two stages of optimizations are going to interact in ghc, if there is a barrier that can only be crossed in one direction)? > The registerised via-C backend should have been retired long ago. It's > time to take it round back and shoot it. We should spend our efforts on > finding a good long-term solution rather than patching this dead-end, IMHO. No disagreement there (apart from the violent metaphor). I'm just worried about pragmatics, ie scuttling the ship before we've counted our life boats!-) And I suspect that for ghc trying to do everything itself on all platforms (rather than trying for very good -fasm on some platforms of interest, and good -fvia-C as a fallback everywhere else) is going to be anything but more work than patching that dead-end (though no doubt more interesting). In other words, what is the plan wrt to backends, especially wrt recovering the optimizations and portability issues previously left to gcc? When will the fast via-C route be retired, what quality of replacement will be in place at that time, how long to catch up to where we are now, how to keep up, etc.? Claus From claus.reinke at talk21.com Fri Mar 6 17:26:49 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Mar 6 17:15:24 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt> <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> Message-ID: > The implementation I'm thinking of is basically trivial. You just add > the information gathered from the pragmas onto the Ids, then have a > dedicated core pass that looks at the pragmas and does it's > worker/wrapper thing. The technology to do peeling/unrolling is > trivial and there already examples in the codebase (in case liberation > and SAT). If someone can spec out what they actually want and GHC HQ > give it the thumbs up I would be happy to do the grunt work on > implementing this feature. Yes, please!-) My preferred spec would be roughly {-# NOINLINE f #-} as now {-# INLINE f #-} works as now, which is for non-recursive f only (might in future be taken as go-ahead for analysis-based recursion unfolding) {-# INLINE f PEEL n #-} inline calls *into* recursive f (called loop peeling for loops) {-# INLINE f UNROLL m #-} inline recursive calls to f *inside* f (called loop unrolling for loops) {-# INLINE f PEEL n UNROLL m #-} combine the previous two The numeric parameters are to be interpreted as if each call to f was annotated with both PEEL and UNROLL limits, to be decreased as appropriate for every PEEL or UNROLL action. Peeling and unrolling stop when the respective count annotation has reached 0. Note that mutual recursion is the domain of PEEL, while UNROLL only applies to direct recursion. {-# INLINE f PEEL n #-}, for n>0, corresponds to worker/ wrapper transforms (previously done manually) + inline wrapper, and should therefore also be taken as a hint for the compiler to try the static argument transformation for f (the "worker"). Non-supporting implementations should treat these as INLINE pragmas (same warning/ignore or automatic unfold behaviour). About the pragma name: as far as I can tell, Hugs simply ignores INLINE pragmas, no matter what they say, other implementations could just ignore the PEEL/UNROLL part (possibly with a warning) - do any of them support INLINE on recursive definitions? The only problem is that GHC itself fails with a parse error, which would lead to version issues (perhaps GHC should have allowed for additional information to otherwise syntactically complete pragmas, or warnings instead of errors, but that hitch is out in the wild now). Having separate PEEL/UNROLL pragmas would make ignoring the default action, but would clutter the pragma name space as well as the source code; it also wouldn't make explicit that we are indeed refining the INLINE pragma for the case of recursive functions (which GHC currently ignores or complains about), by detailing how we want the recursive definition to be inlined. Since we are talking about a refinement of the INLINE pragma, we also need to look at that pragma's existing subtleties:-( - no functions inlined into f: should be subject to override by INLINE pragmas (even for the non-recursive case?) - no float-in/float-out/cse: ?? - no worker/wrapper transform in strictness analyser: we do get the same effect from INLINE PEEL, so this should be okay, right? - loop breakers: PEEL/UNROLL have their own limits, creating an intrinsic loop breaker when the counters run out Is that sufficient? Claus From claus.reinke at talk21.com Fri Mar 6 19:07:34 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Mar 6 18:56:10 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> Message-ID: <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> > My preferred spec would be roughly > > {-# NOINLINE f #-} > as now > > {-# INLINE f #-} > works as now, which is for non-recursive f only (might in future > be taken as go-ahead for analysis-based recursion unfolding) > > {-# INLINE f PEEL n #-} > inline calls *into* recursive f (called loop peeling for loops) > > {-# INLINE f UNROLL m #-} > inline recursive calls to f *inside* f (called loop unrolling for loops) > > {-# INLINE f PEEL n UNROLL m #-} > combine the previous two > > The numeric parameters are to be interpreted as if each call to > f was annotated with both PEEL and UNROLL limits, to be > decreased as appropriate for every PEEL or UNROLL action. hmm, "appropriate" is one of those words that shouldn't occur in specs, not even rough ones, so let's flesh this out a bit, by abstract example. let f = ..f.. in f{n,m} -PEEL-> let f = ..f.. in ..f{n-1,m}.. let f = ..f{n,m}.. in .. -UNROLL-> let f = ..|..f{n,m-1}..|.. in .. In words: the call being peeled/unrolled disappears, being replaced by a copy of the definition, in which the decremented counts are applied to the calls of the same function created by unfolding. Is that specific enough? > Peeling and unrolling stop when the respective count annotation > has reached 0. Note that mutual recursion is the domain of PEEL, > while UNROLL only applies to direct recursion. > > {-# INLINE f PEEL n #-}, for n>0, corresponds to worker/ > wrapper transforms (previously done manually) + inline wrapper, > and should therefore also be taken as a hint for the compiler to > try the static argument transformation for f (the "worker"). > > Non-supporting implementations should treat these as INLINE > pragmas (same warning/ignore or automatic unfold behaviour). > > Since we are talking about a refinement of the INLINE pragma, we > also need to look at that pragma's existing subtleties:-( > > - no functions inlined into f: should be subject to override by > INLINE pragmas (even for the non-recursive case?) > - no float-in/float-out/cse: ?? > - no worker/wrapper transform in strictness analyser: we do get the > same effect from INLINE PEEL, so this should be okay, right? > - loop breakers: PEEL/UNROLL have their own limits, creating > an intrinsic loop breaker when the counters run out Loop breakers are still needed, in spite of the explicit limits. Consider let {odd x = ..even{1,0}..; even x = ..odd{1,0}..} in odd{1,0} n Peeling odd gives a call to even, peeling of which gives a fresh, not decremented, call to odd! Unless one makes a copy of the whole mutual recursion, with the odd calls adjusted. This might be easier to handle in your "unfolding as a separate core2core pass" scenario, where the pass might keep track of unfoldings already done (instead of trying to encode that information locally, in annotations). Other issues? Claus From allbery at ece.cmu.edu Fri Mar 6 20:30:02 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Mar 6 20:18:55 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> Message-ID: <2BB11D9F-5037-4B9A-A62F-EE193E3A1B6C@ece.cmu.edu> On 2009 Mar 6, at 19:07, Claus Reinke wrote: > Loop breakers are still needed, in spite of the explicit limits. > Consider > > let {odd x = ..even{1,0}..; even x = ..odd{1,0}..} in odd{1,0} n {-# INLINE odd even PEEL n #-} ? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090306/450c71f0/PGP.bin From batterseapower at hotmail.com Sat Mar 7 04:28:51 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sat Mar 7 04:17:20 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> References: <20090228174932.GA23519@whirlpool.galois.com> <26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> <9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com> <35DD9685B0814863B1379F2995C81F8C@cr3lt> <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> Message-ID: <9d4d38820903070128l1e561491i15aefe6193e8c916@mail.gmail.com> 2009/3/7 Claus Reinke : > hmm, "appropriate" is one of those words that shouldn't occur in specs, > not even rough ones, so let's flesh this out a bit, by abstract example. > > let f = ..f.. in f{n,m} -PEEL-> let f = ..f.. in ..f{n-1,m}.. Probably what you intend here is that you create one copy of the definition every round rather than one per call site, is that right? In the case of mutual recursion, I suppose something like this should happen: f = ... g ... g = ... f ... ==> f = ... g ... g = ... f ... f1 = ... g ... g1 = ... f ... i.e. after peeling f1 and g1 are free to be inlined into the use site if GHC decides that is a good idea. Similarly for two rounds of peeling you would get: f = ... g ... g = ... f ... f1 = ... g ... g1 = ... f ... f2 = ... g1 ... g2 = ... f1 ... > let f = ..f{n,m}.. in .. -UNROLL-> let f = ..|..f{n,m-1}..|.. in .. Similarly I suppose you intended that you get one copy of the body per UNROLL, rather than per call-site? i.e: f = ... f ... ==> f = ... f1 ... f1 = ... f2 ... f2 = ... f ... I'm not completely convinced that this doesn't make sense for mutual recursion: f = ... g ... g = ... f ... ==> f = ... g ... g = ... f1 ... f1 = ... g1 ... g1 = ... f ... I'm not quite sure how to generalize that though :-) >> ? Non-supporting implementations should treat these as INLINE >> ? pragmas (same warning/ignore or automatic unfold behaviour). Maybe they SHOULD do, but there are a lot of compilers out there in the real world that won't :-). Making these entirely new pragmas feels better to me. I spoke to Simon PJ about these pragmas and he didn't sound terribly enthusiatic - but he suggested they would be a nice use case for compiler plugins :-). Plugins would only be capable of dealing with UNROLL / PEEL as new pragmas. Of course, this kind of relies on us getting plugins into the HEAD sometime... >> - no functions inlined into f: should be subject to override by >> ? INLINE pragmas (even for the non-recursive case?) If UNROLL / PEEL are seperate annotations we won't prevent inlining into the UNROLLed/PEELed thing. But that might be bad! What if we have: x = BIG {-# UNROLL f 3 #-} f = ... x ... f ... Now if we unconditionally inline x into f as the only use site we will end up bloating up the code if we later run the unroller. However, if we unroll first then the simplifier won't inline x and things will be good. So perhaps you are right to say that this should be an extension of INLINE. As for the more general question about whether you should inline stuff inside INLINEs at all - well, AFAIK the latest work on this by Simon means that stuff /will/ be inlined inside them, but if that body is subsequently inlined what gets inlined is the /original/ body as the user wrote it in his source code. This improves performance when for some reason a value doesn't get inlined. >> - no float-in/float-out/cse: ?? The restriction on CSE is principally for NOINLINE things, to prevent messing with RULEs by changing identifiers around. I'm not sure if that is relevant here. No float-in makes sure we don't increase the size of things we are going to INLINE. This is important with UNROLL / PEEL for the same reason as above - another argument for this being an extension of INLINE so we inherit its semantics. I don't actually know why the no-float-out restriction exists (after all, it only makes the body smaller!) so I'm not sure what the right thing to do would be there. >> - no worker/wrapper transform in strictness analyser: we do get the ? same >> effect from INLINE PEEL, so this should be okay, right? Maybe I don't understand what you mean, but I don't think this is true. For example, w/w can unpack a strict argument of product type, but I dont' think PEEL will let you achieve that. This restriction exists to prevent losing INLINE pragmas: """ Note [Don't w/w inline things] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's very important to refrain from w/w-ing an INLINE function If we do so by mistake we transform f = __inline (\x -> E) into f = __inline (\x -> case x of (a,b) -> fw E) fw = \ab -> (__inline (\x -> E)) (a,b) and the original __inline now vanishes, so E is no longer inside its __inline wrapper. Death! Disaster! """ So we might want to prevent w/wing UNROLL/PEEL for the same reasons.. but if we do the UNROLL/PEEL "pass" early enough (i.e. before strictness - which is quite late in the pipeline) then this issue will go away. >> - loop breakers: PEEL/UNROLL have their own limits, creating >> ? an intrinsic loop breaker when the counters run out > This might be easier to > handle in your "unfolding as a separate core2core pass" scenario, where the > pass might keep track of unfoldings already done (instead of trying to > encode that information locally, in annotations). I think that makes most sense. If we run it early enough we would be reasonably sure our program was close to what the user intended and hence could sidestep some of the restrictions on INLINE pragmas that are discussed above by simply not applying them to UNROLL/PEEL, though this doesn't feel like a terribly satisfactory solution. Cheers, Max From tuomov at iki.fi Sun Mar 8 08:29:20 2009 From: tuomov at iki.fi (Tuomo Valkonen) Date: Sun Mar 8 08:43:28 2009 Subject: Cygwin version Message-ID: I want a _real_ cygwin version of darcs. The non-deterministic pseudo-cygwin *nix/Windows hybrid currently available has just too many problems integrating into cygwin, that I want to use as my TeXing and minor coding environment. A real cygwin version of darcs would seem to depend on a real cygwin version of GHC. Is there any easy way to compile one? Otherwise I may have to abandon darcs (and Haskell software in general) for Mercurial. (Thanks to the over-bearing cabal and resulting hsc2hs etc. build problems with conventional Makefiles, I have already pretty much already abandoned my own Haskell projects.) -- Stop Gnomes and other pests! Purchase Windows today! From dons at galois.com Sun Mar 8 15:54:22 2009 From: dons at galois.com (Don Stewart) Date: Sun Mar 8 15:43:38 2009 Subject: Cygwin version In-Reply-To: References: Message-ID: <20090308195422.GC24228@whirlpool.galois.com> tuomov: > I want a _real_ cygwin version of darcs. The non-deterministic > pseudo-cygwin *nix/Windows hybrid currently available has just > too many problems integrating into cygwin, that I want to use as > my TeXing and minor coding environment. A real cygwin version > of darcs would seem to depend on a real cygwin version of GHC. > Is there any easy way to compile one? Otherwise I may have to > abandon darcs (and Haskell software in general) for Mercurial. > > (Thanks to the over-bearing cabal and resulting hsc2hs etc. > build problems with conventional Makefiles, I have already > pretty much already abandoned my own Haskell projects.) > "Here is a complete, from-scratch, log of all you need to build GHC using Cygwin, kindly provided by Claus Reinke. " http://hackage.haskell.org/trac/ghc/wiki/Building/Windows#AWindowsbuildlogusingCygwin From tuomov at iki.fi Sun Mar 8 16:24:34 2009 From: tuomov at iki.fi (Tuomo Valkonen) Date: Sun Mar 8 16:13:10 2009 Subject: Cygwin version References: <20090308195422.GC24228@whirlpool.galois.com> Message-ID: On 2009-03-08, Don Stewart wrote: > "Here is a complete, from-scratch, log of all you need to build GHC > using Cygwin, kindly provided by Claus Reinke. " > > http://hackage.haskell.org/trac/ghc/wiki/Building/Windows#AWindowsbuildlogusingCygwin These appear to be instructions to build a Windows version _using Cygwin_. I wanted a _real_ Cygwin version of GHC that builds Cygwin binaries, providing Cygwin POSIX functionality, etc. -- In 1995, Linux was almost a bicycle; an alternative way of live to the Windows petrol beasts that had to be taken to the dealer for service. By 2008, Linux has bloated into a gas-guzzler, and local vendors and artisans have had to yield to "all under one roof" big box hypermarkets. From john at repetae.net Sun Mar 8 18:48:24 2009 From: john at repetae.net (John Meacham) Date: Sun Mar 8 18:36:48 2009 Subject: Cygwin version In-Reply-To: References: <20090308195422.GC24228@whirlpool.galois.com> Message-ID: <20090308224824.GA8842@sliver.repetae.net> On Sun, Mar 08, 2009 at 08:24:34PM +0000, Tuomo Valkonen wrote: > On 2009-03-08, Don Stewart wrote: > > "Here is a complete, from-scratch, log of all you need to build GHC > > using Cygwin, kindly provided by Claus Reinke. " > > > > http://hackage.haskell.org/trac/ghc/wiki/Building/Windows#AWindowsbuildlogusingCygwin > > These appear to be instructions to build a Windows version _using Cygwin_. > I wanted a _real_ Cygwin version of GHC that builds Cygwin binaries, > providing Cygwin POSIX functionality, etc. if you follow those steps, but then don't override the host in the ./configure step to just let it pick up the cygwin environment will it work properly? John -- John Meacham - ?repetae.net?john? From tuomov at iki.fi Sun Mar 8 19:46:07 2009 From: tuomov at iki.fi (Tuomo Valkonen) Date: Sun Mar 8 19:34:45 2009 Subject: Cygwin version References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> Message-ID: On 2009-03-08, John Meacham wrote: > if you follow those steps, but then don't override the host in the > ./configure step to just let it pick up the cygwin environment will it > work properly? > > John No: Configuring extensible-exceptions-0.1.0.0... cabal-bin.exe: Cannot find the program 'ghc' at '/c/bin/ghc-6.10.1.20090308/bin/ghc' or on the path 'ldd libraries/cabal-bin.exe' finds no cygwin dependencies; everything points to /c/WINDOWS/system32. I presume that the mingw-ghc used the include mingw gcc, not cygwin's gcc. Indeed, I tried deleting that file, and got: ghc.exe: could not execute: C:\bin\ghc-6.10.1.20090308\gcc It doesn't seem like it will build cygwin programs. -- Stop Gnomes and other pests! Purchase Windows today! From rl at cse.unsw.edu.au Mon Mar 9 00:16:25 2009 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Mon Mar 9 00:04:58 2009 Subject: Loop unrolling + fusion ? In-Reply-To: References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt> <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> Message-ID: <84586116-A34E-4980-B5DD-974AAE54DE61@cse.unsw.edu.au> On 07/03/2009, at 09:26, Claus Reinke wrote: > My preferred spec would be roughly > > {-# NOINLINE f #-} > as now > > {-# INLINE f #-} works as now, which is for non-recursive f only > (might in future > be taken as go-ahead for analysis-based recursion unfolding) > > {-# INLINE f PEEL n #-} > inline calls *into* recursive f (called loop peeling for loops) > {-# INLINE f UNROLL m #-} > inline recursive calls to f *inside* f (called loop unrolling for > loops) > > {-# INLINE f PEEL n UNROLL m #-} > combine the previous two The problem here is that this only works for directly recursive functions which I, for instance, don't normally use in high- performance code. Most of my loops are pipelines of collective combinators like map, filter, fold etc. because these are the ones that can be fused automatically. Unless I'm misunderstanding something, this approach doesn't handle such cases. Roman From ndmitchell at gmail.com Mon Mar 9 05:54:18 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 9 05:42:41 2009 Subject: finally part run twice on Ctrl-C In-Reply-To: <200902270945.15389.p.k.f.holzenspies@utwente.nl> References: <20090227000312.9C58E32440B@www.haskell.org> <200902270937.18492.p.k.f.holzenspies@utwente.nl> <404396ef0902270039i5adbc37fufd623d704eebc5ce@mail.gmail.com> <200902270945.15389.p.k.f.holzenspies@utwente.nl> Message-ID: <404396ef0903090254p50ece9a6h974cdd67a419bd19@mail.gmail.com> Hi I have filed bug http://hackage.haskell.org/trac/ghc/ticket/3081 to track this issue, marking it as effecting Windows only. Thanks Neil On Fri, Feb 27, 2009 at 8:45 AM, Philip K.F. H?lzenspies wrote: > On Friday 27 February 2009 09:39:14 Neil Mitchell wrote: >> It looks like you are running in GHCi, which I think works. It's only >> when the program is compiled and run from the command line (Cygwin or >> DOS) that I get the above problem. > > Dear Neil, > > You were right. When I do compile it, though, I get the same (correct) > behaviour (now I pressed Ctrl-C the first run and let it be for the second): > > holzensp@ewi1043:~/tmp> ghc Test.hs > holzensp@ewi1043:~/tmp> ./a.out > goodbye > holzensp@ewi1043:~/tmp> ./a.out > goodbye > holzensp@ewi1043:~/tmp> > > This is on Linux, though, so it may also be OS-dependent. > > Regards, > Philip > From batterseapower at hotmail.com Mon Mar 9 05:58:20 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Mar 9 05:46:42 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <84586116-A34E-4980-B5DD-974AAE54DE61@cse.unsw.edu.au> References: <20090228174932.GA23519@whirlpool.galois.com> <26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> <9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com> <35DD9685B0814863B1379F2995C81F8C@cr3lt> <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <84586116-A34E-4980-B5DD-974AAE54DE61@cse.unsw.edu.au> Message-ID: <9d4d38820903090258p453bbe3bra1d7eb6e316f2ed5@mail.gmail.com> 2009/3/9 Roman Leshchinskiy : > The problem here is that this only works for directly recursive functions > which I, for instance, don't normally use in high-performance code. Most of > my loops are pipelines of collective combinators like map, filter, fold etc. > because these are the ones that can be fused automatically. Unless I'm > misunderstanding something, this approach doesn't handle such cases. Yep, I think this is an orthogonal piece of functionality. I believe Claus is concerned with getting the compiler to perform some of the transformations people currently might want to do for their directly recursive functions. Of course, you could still UNROLL your unstream definition, but that doesn't give the user any control over the amount of unrolling that takes place, which as you have pointed out earlier may not be a great idea! Cheers, Max From colin at colina.demon.co.uk Mon Mar 9 07:24:56 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Mar 9 07:13:23 2009 Subject: Reliability of trace? Message-ID: I'm trying to use Debug.Trace to debug some tree-walking that I've written. It seems to me that I am missing some traces on intermediate function calls. I guess that ghc is re-arranging the code in such a way that some of these intermediate calls disappear. Anyway of stopping this? I already specify -O0. -- Colin Adams Preston Lancashire From marlowsd at gmail.com Mon Mar 9 08:15:16 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Mar 9 08:03:43 2009 Subject: a possibility to redefine built-in GHCi commands In-Reply-To: References: Message-ID: <49B50854.1040204@gmail.com> Peter Hercek wrote: > Hi GHCi users, > > I would like to be able to redefine the built-in GHCi commands. The idea > is that when searching for a command the user defined commands would be > searched first and only then the built-in commands would be searched. If > user wants to invoke a built-in command regardless of user defined > commands he/she would need to start it with two colons (instead of one). > > It is an user interface change which may break some scripts, but it > would allow to provide different default behavior. > For example: > * when I use GhciExt I want all my ":continue" commands to be actually > ":x :continue" > * it would allow to specify different order of searching for abbreviated > commands as the default one > * it would allow to specify different default switches for builtin commands > > Would such a change be merged upstream if I would provide a patch? Seems reasonable to me. Cheers, Simon From marlowsd at gmail.com Mon Mar 9 08:19:59 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Mar 9 08:08:34 2009 Subject: Cygwin version In-Reply-To: References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> Message-ID: <49B5096F.5030205@gmail.com> Tuomo Valkonen wrote: > On 2009-03-08, John Meacham wrote: >> if you follow those steps, but then don't override the host in the >> ./configure step to just let it pick up the cygwin environment will it >> work properly? >> >> John > > No: > > Configuring extensible-exceptions-0.1.0.0... > cabal-bin.exe: Cannot find the program 'ghc' at > '/c/bin/ghc-6.10.1.20090308/bin/ghc' or on the path > > 'ldd libraries/cabal-bin.exe' finds no cygwin dependencies; > everything points to /c/WINDOWS/system32. I presume that > the mingw-ghc used the include mingw gcc, not cygwin's gcc. > Indeed, I tried deleting that file, and got: > > ghc.exe: could not execute: C:\bin\ghc-6.10.1.20090308\gcc > > It doesn't seem like it will build cygwin programs. There's no fundamental reason why there can't be a "real" Cygwin GHC (that is, a GHC producing binaries that are linked against the Cygwin DLL). Indeed it used to work, a long time ago. But due to lack of demand it bitrotted. I imagine it would be a fair amount of work to get it going again, but of greater concern to me is how we would *keep* it working: there needs to be interested people actively maintaining buildbots and catching bitrot as it happens. Without a sustainable process, there isn't a great deal of point in updating the port. Cheers, Simon From john at repetae.net Mon Mar 9 08:36:41 2009 From: john at repetae.net (John Meacham) Date: Mon Mar 9 08:25:01 2009 Subject: Cygwin version In-Reply-To: References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> Message-ID: <20090309123640.GC8842@sliver.repetae.net> On Sun, Mar 08, 2009 at 11:46:07PM +0000, Tuomo Valkonen wrote: > No: > > Configuring extensible-exceptions-0.1.0.0... > cabal-bin.exe: Cannot find the program 'ghc' at > '/c/bin/ghc-6.10.1.20090308/bin/ghc' or on the path > > 'ldd libraries/cabal-bin.exe' finds no cygwin dependencies; > everything points to /c/WINDOWS/system32. I presume that > the mingw-ghc used the include mingw gcc, not cygwin's gcc. > Indeed, I tried deleting that file, and got: > > ghc.exe: could not execute: C:\bin\ghc-6.10.1.20090308\gcc > > It doesn't seem like it will build cygwin programs. perhaps the most recent non-cabalized ghc build might be worth a try. I think darcs still compiles with ghc 6.6, but am not positive., I seem to remember ghc working on cygwin at some point. I have been in a similar position in the past actually in the odd place of developing linux/unix software while sitting at a windows box, and cygwin builds of tools were more useful in general. John -- John Meacham - ?repetae.net?john? From duncan.coutts at worc.ox.ac.uk Mon Mar 9 08:41:33 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 9 08:29:58 2009 Subject: Cygwin version In-Reply-To: References: Message-ID: <1236602493.22402.333.camel@localhost> On Sun, 2009-03-08 at 12:29 +0000, Tuomo Valkonen wrote: > I want a _real_ cygwin version of darcs. The non-deterministic > pseudo-cygwin *nix/Windows hybrid currently available has just > too many problems integrating into cygwin, that I want to use as > my TeXing and minor coding environment. A real cygwin version > of darcs would seem to depend on a real cygwin version of GHC. > Is there any easy way to compile one? Otherwise I may have to > abandon darcs (and Haskell software in general) for Mercurial. > > (Thanks to the over-bearing cabal and resulting hsc2hs etc. > build problems with conventional Makefiles, I have already > pretty much already abandoned my own Haskell projects.) Yes we did introduce a problem with hsc2hs in the most recent ghc release and I'm sorry about that. Just in case you're interested however, the fix for your makefiles is to add two flags: hsc2hs --cc=ghc --ld=ghc That should work with any version of hsc2hs and it gives the behaviour of the older hsc2hs versions that came with older ghc releases. Duncan From tuomov at iki.fi Mon Mar 9 08:58:14 2009 From: tuomov at iki.fi (Tuomo Valkonen) Date: Mon Mar 9 08:46:45 2009 Subject: Cygwin version References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> <20090309123640.GC8842@sliver.repetae.net> Message-ID: On 2009-03-09, John Meacham wrote: > perhaps the most recent non-cabalized ghc build might be worth a try. I > think darcs still compiles with ghc 6.6, but am not positive., Mingw-bootstrap, source, or both? > remember ghc working on cygwin at some point. I have been in a similar > position in the past actually in the odd place of developing linux/unix > software while sitting at a windows box, and cygwin builds of tools were > more useful in general. I'm just planning on keeping the good bits of the *nix toolchain while switching to another OS from Linux (or *BSD) that keeps burying those pieces under layers upon layers of stinking and unreliable gnomeshit, and that suffers from de facto central control over software distribution. The only choice is Windows, because Apple is just too steve-jobs-knows-what-you-want, although would otherwise offer a better *nix environment. -- "[Fashion] is usually a form of ugliness so intolerable that we have to alter it every six months." -- Oscar Wilde "The computer industry is the only industry that is more fashion-driven than women's fashion." -- RMS From claus.reinke at talk21.com Mon Mar 9 09:18:32 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Mar 9 09:06:58 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com><43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> <9d4d38820903070128l1e561491i15aefe6193e8c916@mail.gmail.com> Message-ID: >> let f = ..f.. in f{n,m} -PEEL-> let f = ..f.. in ..f{n-1,m}.. >Probably what you intend here is that you create one copy of the >definition every round rather than one per call site, is that right? I don't think so - ultimately, the point of both peeling and unrolling is to unfold a definition into a use site, to enable further optimizations, not just to move from a recursive to a non-recursive definition. We could try to do it in two steps, as you suggest, but that would expose us to the heuristics of GHC inlining again (will or won't it inline the new shared definition?), in the middle of a user-annotation-based unfolding. As for the remainder of your useful reply, I'll have to think more about how to make a local-rule-based approach work properly (without the hickups of my first sketch) before I can think about the interactions. I still think it would be useful to have such a rule-based description, even if a monolithic core2core pass may be easier to implement: having two independent specs makes it easier to spot inconsistencies, and if the rule-based form doesn't get too complicated, it should be more suited for documentation. Claus From claus.reinke at talk21.com Mon Mar 9 09:32:58 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Mar 9 09:21:30 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <84586116-A34E-4980-B5DD-974AAE54DE61@cse.unsw.edu.au> Message-ID: >> {-# INLINE f PEEL n #-} >> inline calls *into* recursive f (called loop peeling for loops) >> {-# INLINE f UNROLL m #-} >> inline recursive calls to f *inside* f (called loop unrolling for >> loops) >> >> {-# INLINE f PEEL n UNROLL m #-} >> combine the previous two > > The problem here is that this only works for directly recursive > functions which I, for instance, don't normally use in high- > performance code. Most of my loops are pipelines of collective > combinators like map, filter, fold etc. because these are the ones > that can be fused automatically. Unless I'm misunderstanding > something, this approach doesn't handle such cases. Actually, my first sketch had a problem in that it would work only too well for mutually recursive functions, making it necessary to use loop breakers in spite of the explicit limits (even if we limit unroll to direct recursion, as I intended originally, peeling would then apply to the calls into other functions in the recursion). One way out would be to treat the whole mutual recursion as a single entity, either implicitly, as I indicated, or explicitly, as I interpret Brandon's somewhat ambiguous comment. In other words, the peel/unroll limits would apply to a whole group of mutually recursive definitions, ensuring termination of the inline process without additional loop breakers. If we do that, then it might make sense to talk about peeling/unrolling wrt the whole recursion group. In any case, I need to refine my spec!-) But this discussion is very helpful in finding the issues that need to be addressed and clarified. Another issue that I ran into in manual unrolling is that I sometimes want to unroll wrt a specific parameter of a multi- parameter function, usually because that parameter can only have a very small numer of possible values, or just because the original function encodes multiple loops that I want to disentangle. Claus From marlowsd at gmail.com Mon Mar 9 11:14:07 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Mar 9 11:02:39 2009 Subject: Loop unrolling + fusion ? In-Reply-To: References: <20090228174932.GA23519@whirlpool.galois.com> <49B12BC5.8090008@gmail.com> Message-ID: <49B5323F.6040601@gmail.com> Claus Reinke wrote: >>> That was one of my questions in the optimization and rewrite rules >>> thread: shouldn't -fvia-C be supported (as a non-default option) >>> for at least as long as the alternative isn't a clear win in all cases? >> >> The trouble with supporting multiple backends is that the cost in >> terms of testing and maintenance is high. And the registerised >> -fvia-C backend is particularly nasty, coming as it does with >> thousands of lines of Perl 4 that regularly get broken by new versions >> of gcc. > > Yes, I can understand that you'd like to leave that part behind sometime > before yesterday:-) I assume that this very complexity means that the > -fvia-C route doesn't really get all the way to its most interesting > promises (easy portability, and full backend optimizations inherited > from gcc). And with that in mind, I can also understand that you don't > want to put in any further work into trying to improve it, if that > distracts from a better long-term solution. > What I don't understand yet is the routemap for replacing -fvia-C. We've > seen -fvia-C being demoted from default to backup (fine by me), we've > seen a feature supported only by -fvia-C removed completely, instead of > seeing support for it added to the -fasm route (macro-based APIs > used to work with ffi, would now require a wrapper generator, which > doesn't exist yet). > Indications are that -fvia-C still tends to produce better code (even > though it is not the best that ghc+gcc could produce) than -fasm (is > that any better for the new backend?). And last, but not least, ghc has > more limited resources than gcc, so how is ghc going to beat gcc at the > portability and backend optimizations game while still making progress > in its core competencies (ie, higher-level improvements; there's also > the interesting side-issue of how the two stages of optimizations are > going to interact in ghc, if there is a barrier that can only be crossed > in one direction)? Ok, thanks for bringing these points up. Hopefully I'll be able to lay your fears to rest: 1. Performance. -fvia-c currently produces code that is on average about 1% faster than -fasm: http://www.cse.unsw.edu.au/~dons/nobench/x86_64/results.html There's one notable exception: floating-point code on x86 (not x86_64) is terrible with -fasm, because our native code generator has a particularly simple/stupid implementation of the x87 instruction set. So we need to make the SSE2 code generator in the x86_64 backend work for x86, too. Having said that, the native backend has much more potential for generating faster code than we can with gcc. Firstly, it can re-use fixed registers (e.g. argument registers) within a basic block, whereas gcc can't. We don't do this currently because the C-- lacks the liveness information on jumps, but the new backend will be able to do it. I bet this alone will be worth more than that 1%. Secondly we have a much better handle on aliasing inside GHC than gcc does, and there's no good way to tell gcc what we know about aliasing. On x86, gcc has a grand total of 2 spare registers, which means it has virtually no scope for generating good code. There's also not much room for generating C that is more amenable to gcc's optimisations. The obvious thing to do is to make recursive functions look like loops. We've tried it (there's some experimental code in GHC to do it), IIRC it didn't buy very much. The lack of registers, and the lack of knowledge about aliasing (heap doesn't alias with stack) meant that gcc didn't do some obvious-looking optimisations. Trying to do better here is a dead end. 2. Portability. We haven't had a single new registerised port of GHC in many years now. While the via-C backend seems at first glance to offer some portability benefits, in practice porting the mangler is still a pain unless your platform is very similar to an existing one (e.g. vanilla ELF). The only C-only registerised port we had was Sparc, and thanks to Ben Lippmeier we now have a native backend for that too. Dropping the C backend won't harm any of our existing ports, and it doesn't seem like people are making new ports of GHC this way either. We'll still have the unregisterised porting route, whose only drawback is performance. Still, lots of platforms are successfully using unregisterised GHC ports (via Debian). One day maybe we'll have an LLVM backend, or similar. My impression is that right now we can't make an LLVM backend with as good performance as our native backend, without changes in LLVM. Maybe that will change. Nothing that we're doing now precludes adding an LLVM backend later, I believe. 3. Features. This is a non-issue: -fvia-C vs. -fasm should not affect what programs work. Up until 6.10.1 we had a bug whereby you could use -fvia-C to bind to CPP-based C APIs, but that bug was removed in 6.10.1. Ok, I realise that some people considered this to be a feature and its removal to be a regression. However, I believe it's more important that we conform to the FFI spec, and for -fasm to be consistent with -fvia-C. It's a slight inconvenience to have to write the wrappers, but in return you get more robust code. Of course we should have tool support to make generating the wrappers easier. Cheers, Simon From simonpj at microsoft.com Mon Mar 9 11:56:14 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Mar 9 11:44:38 2009 Subject: Type functions and ambiguity In-Reply-To: <200903052207.40062.dan.doel@gmail.com> References: <200903052207.40062.dan.doel@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C334CB71C534@EA-EXMSG-C334.europe.corp.microsoft.com> Dan's example fails thus: | Map.hs:25:19: | Couldn't match expected type `Nest n1 f b' | against inferred type `Nest n1 f1 b' | In the expression: fmap (deepFMap n f) | In the definition of `deepFMap': | deepFMap (S n) f = fmap (deepFMap n f) | | for reasons I don't really understand. So I tried the following: For what it's worth, here's why. Suppose we have type family N a :: * f :: forall a. N a -> Int f = g :: forall b. N b -> Int g x = 1 + f x The defn of 'g' fails with a very similar error to the one above. Here's why. We instantiate the occurrence of 'f' with an as-yet-unknown type 'alpha', so at the call site 'f' has type N alpha -> Int Now, we know from g's type sig that x :: N b. Since f is applies to x, we must have N alpha ~ N b Does that imply that (alpha ~ b)? Alas no! If t1=t2 then (N t1 = N t2), of course, but *not* vice versa. For example, suppose that type instance N [c] = N c Now we could solve the above with (alpha ~ [b]), or (alpha ~ [[b]]). You may say a) There is no such instance. Well, but you can see it pushes the search for a (unique) solution into new territory. b) It doesn't matter which solution the compiler chooses: any will do. True in this case, but false if f :: forall a. (Num a) => N a -> Int. Now it matters which instance is chosen. This kind of example encapsulates the biggest single difficulty with using type families in practice. What is worse is that THERE IS NO WORKAROUND. You *ought* to be able to add an annotation to guide the type checker. Currently you can't. The most obvious solution would be to allow the programmer to specify the types at which a polymorphic function is called, like this: g :: forall b. N b -> Int g x = 1 + f {b} x The {b} says that f takes a type argument 'b', which should be used to instantiate its polymorphic type variable 'a'. Being able to do this would be useful in other circumstances (eg impredicative polymorphism). The issue is really the syntax, and the order of type variables in an implicit forall. Anyway I hope this helps clarify the issue. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Dan Doel | Sent: 06 March 2009 03:08 | To: glasgow-haskell-users@haskell.org | Subject: Deep fmap with GADTs and type families. | | Greetings, | | Someone on comp.lang.functional was asking how to map through arbitrary | nestings of lists, so I thought I'd demonstrate how his non-working ML | function could actually be typed in GHC, like so: | | --- snip --- | | {-# LANGUAGE TypeFamilies, GADTs, EmptyDataDecls, | Rank2Types, ScopedTypeVariables #-} | | data Z | data S n | | data Nat n where | Z :: Nat Z | S :: Nat n -> Nat (S n) | | type family Nest n (f :: * -> *) a :: * | | type instance Nest Z f a = f a | type instance Nest (S n) f a = f (Nest n f a) | | deepMap :: Nat n -> (a -> b) -> Nest n [] a -> Nest n [] b | deepMap Z f = map f | deepMap (S n) f = map (deepMap n f) | | --- snip --- | | This works. However, the straight forward generalisation doesn't: | | --- snip --- | | deepFMap :: Functor f => Nat n -> (a -> b) -> Nest n f a -> Nest n f b | deepFMap Z f = fmap f | deepFMap (S n) f = fmap (deepFMap n f) | | --- snip --- | | This fails with a couple errors like: | | Map.hs:25:19: | Couldn't match expected type `Nest n1 f b' | against inferred type `Nest n1 f1 b' | In the expression: fmap (deepFMap n f) | In the definition of `deepFMap': | deepFMap (S n) f = fmap (deepFMap n f) | | for reasons I don't really understand. So I tried the following: | ...rest snipped... From tuomov at iki.fi Mon Mar 9 11:59:16 2009 From: tuomov at iki.fi (Tuomo Valkonen) Date: Mon Mar 9 11:47:55 2009 Subject: Cygwin version References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> <20090309123640.GC8842@sliver.repetae.net> Message-ID: On 2009-03-09, Tuomo Valkonen wrote: > On 2009-03-09, John Meacham wrote: >> perhaps the most recent non-cabalized ghc build might be worth a try. I >> think darcs still compiles with ghc 6.6, but am not positive., > > Mingw-bootstrap, source, or both? Tried with both. Got: ghc.exe: unknown package: unix -- Be an early adopter! Beat the herd! Choose Windows today! From dan.doel at gmail.com Mon Mar 9 12:46:01 2009 From: dan.doel at gmail.com (Dan Doel) Date: Mon Mar 9 12:34:26 2009 Subject: Type functions and ambiguity In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C334CB71C534@EA-EXMSG-C334.europe.corp.microsoft.com> References: <200903052207.40062.dan.doel@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C334CB71C534@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200903091246.02115.dan.doel@gmail.com> On Monday 09 March 2009 11:56:14 am Simon Peyton-Jones wrote: > For what it's worth, here's why. Suppose we have > > type family N a :: * > > f :: forall a. N a -> Int > f = > > g :: forall b. N b -> Int > g x = 1 + f x > > The defn of 'g' fails with a very similar error to the one above. Here's > why. We instantiate the occurrence of 'f' with an as-yet-unknown type > 'alpha', so at the call site 'f' has type N alpha -> Int > Now, we know from g's type sig that x :: N b. Since f is applies to x, we > must have N alpha ~ N b I think this explains my confusion. I was thinking roughly in terms like, "I need 'N b -> Int'; I have 'forall a. N a -> Int', so instantiate 'a' to 'b'." Not in terms of collecting constraints and unifying after the fact. From the latter perspective the ambiguity makes sense. > This kind of example encapsulates the biggest single difficulty with using > type families in practice. What is worse is that THERE IS NO WORKAROUND. I suppose one can always add arguments like the "Proxy" to functions to disambiguate, but that certainly isn't ideal. > Anyway I hope this helps clarify the issue. Yes; thanks. -- Dan From batterseapower at hotmail.com Mon Mar 9 13:04:16 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Mar 9 12:52:37 2009 Subject: Loop unrolling + fusion ? In-Reply-To: References: <20090228174932.GA23519@whirlpool.galois.com> <26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> <9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com> <35DD9685B0814863B1379F2995C81F8C@cr3lt> <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> <9d4d38820903070128l1e561491i15aefe6193e8c916@mail.gmail.com> Message-ID: <9d4d38820903091004i394c3757h69c6ba27ffd89af7@mail.gmail.com> 2009/3/9 Claus Reinke : >>> let f = ..f.. in f{n,m} -PEEL-> let f = ..f.. in ..f{n-1,m}.. > >> Probably what you intend here is that you create one copy of the >> definition every round rather than one per call site, is that right? > > I don't think so - ultimately, the point of both peeling and unrolling is to > unfold a definition into a use site, to enable further optimizations, not > just to move from a recursive to a non-recursive definition. We could try to > do it in two steps, as you suggest, but that would expose us to the > heuristics of GHC inlining again (will or won't it inline the > new shared definition?), in the middle of a user-annotation-based unfolding. Ah - I was thinking of something a bit different, where: * PEEL / UNROLL pragmas duplicate the method body once per level of peeling / unrolling and fix up the recursive calls as appropriate * The user optionally adds an INLINE pragma to the function if he additionally wants to be SURE that those duplicates get inlined at the use sites This means that PEEL / UNROLL represent nice logically-orthogonal bits of functionality to INLINE-ing. Furthermore, I'm not too keen on duplicating method bodies at call sites willy-nilly because it may lead to increased allocations (of the function closures) in inner loops. At least if you bind the duplicated methods at the same level as the thing you are duplicating you only increase the dynamic number of closures created by a constant factor! I've actually been thinking about using a different strategy for case liberation (which duplicates method bodies at call sites) to make it more constructor-specialisation like (which duplicates method bodies at the definition site) partly for this reason. Cheers, Max From twhitehead at gmail.com Mon Mar 9 17:14:12 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Mar 9 17:02:40 2009 Subject: GHC and Haskell Standard wrt floatRange... Message-ID: <200903091714.17985.twhitehead@gmail.com> I think there might be a difference between C/GHC and the Haskell Standard's idea of the range of the exponential. Specifically, the comment in gcc's float.h (i.e., where GHC appears to gets its definition from) says /* Minimum int x such that FLT_RADIX**(x-1) is a normalized float, emin */ while the Haskell Standard says "...the lowest and highest values the exponent may assume respectively..." This results in (GHC 6.10.1 on Debian) Prelude> (2**128::Float) Infinity Prelude> (2**127::Float) 1.7014119e38 Prelude> floatRange (0::Float) (-125,128) I can file a bug report/patch if nobody is seeing something I missed here... Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090309/db1fcd33/attachment.bin From claus.reinke at talk21.com Mon Mar 9 18:44:27 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Mar 9 18:32:53 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com><43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt><9d4d38820903070128l1e561491i15aefe6193e8c916@mail.gmail.com> <9d4d38820903091004i394c3757h69c6ba27ffd89af7@mail.gmail.com> Message-ID: <34D927A90FC84139BEAEEBB8D6D2B551@cr3lt> >>>> let f = ..f.. in f{n,m} -PEEL-> let f = ..f.. in ..f{n-1,m}.. >> >>> Probably what you intend here is that you create one copy of the >>> definition every round rather than one per call site, is that right? >> >> I don't think so - ultimately, the point of both peeling and unrolling is to >> unfold a definition into a use site, to enable further optimizations, not >> just to move from a recursive to a non-recursive definition. We could try to >> do it in two steps, as you suggest, but that would expose us to the >> heuristics of GHC inlining again (will or won't it inline the >> new shared definition?), in the middle of a user-annotation-based unfolding. > > Ah - I was thinking of something a bit different, where: > > * PEEL / UNROLL pragmas duplicate the method body once per level of > peeling / unrolling and fix up the recursive calls as appropriate > * The user optionally adds an INLINE pragma to the function if he > additionally wants to be SURE that those duplicates get inlined at the > use sites Ok, I suspected as much. You'd need to make the 'INLINE f' apply to the generated 'fN', of course. > This means that PEEL / UNROLL represent nice logically-orthogonal bits > of functionality to INLINE-ing. Usually, I'm all for orthogonality, and for more knobs to allow hand-tuning of things that have no automatically reachable optimal solutions. In this case, however, I'm not sure anything would be gained. I recall that your hand- unrolled code was written in a similar style, and assumed that it was a question of style, which GHC would inline into the same code. But if you annotate all your unrolled and peeled new definitions as NOINLINE, do you still get the optimizations you want? There are probably a few GHC optimizations that can "look through" non-recursive lets, but RULES are not among those. For loop-style recursion, there'd be only one use per definition, so inlining would be the default and there'd be no difference, but for non-loop-style recursion, inlining might not happen, and so no further optimizations would be enabled. Off the top of my head, I can't think of a case where that would lead to improved code, but as I'm discovering, I'm not very familiar with the details of what optimizations GHC is actually doing (though this is quite helpful: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/HscMain ) so I might be missing something? > Furthermore, I'm not too keen on duplicating method bodies at call > sites willy-nilly because it may lead to increased allocations (of the > function closures) in inner loops. At least if you bind the duplicated > methods at the same level as the thing you are duplicating you only > increase the dynamic number of closures created by a constant factor! Yes, every form of INLINE has its limits. But if users say they want inlining (or peeling or unrolling or any other form of unfolding), that's what they should get, including those worrysome duplications. The idea is to create lots of added code (in order to remove abstractions that might hide optimization opportunities), which will then be simplified to something smaller (or at least better performing) than what we started out with. Providing the means to fine tune the amount of duplications might be useful, but preventing them entirely is not an option. Claus From batterseapower at hotmail.com Mon Mar 9 20:46:17 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Mon Mar 9 20:34:39 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <34D927A90FC84139BEAEEBB8D6D2B551@cr3lt> References: <20090228174932.GA23519@whirlpool.galois.com> <9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com> <35DD9685B0814863B1379F2995C81F8C@cr3lt> <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> <9d4d38820903070128l1e561491i15aefe6193e8c916@mail.gmail.com> <9d4d38820903091004i394c3757h69c6ba27ffd89af7@mail.gmail.com> <34D927A90FC84139BEAEEBB8D6D2B551@cr3lt> Message-ID: <9d4d38820903091746l4cfa9944x457a36e3c25fcc17@mail.gmail.com> 2009/3/9 Claus Reinke : But if you annotate all your unrolled and peeled new definitions as > NOINLINE, do you still get the optimizations you want? There are probably a > few GHC optimizations that can "look through" non-recursive > lets, but RULES are not among those. The benefit that comes immediately to mind is extra freedom for the code generator. If we have several copies of the body of e.g. a loop it may be able to schedule instructions much better. This is why GCC unrolls loops, of course. Of course, Core may not be the best place to do this sort of unrolling as Roman pointed out earlier in the thread. But yeah, beyond this I don't /think/ that non-inlined duplications would help GHC at all (it might be a different story if we did partial inlining). All the best, Max From allbery at ece.cmu.edu Mon Mar 9 23:40:00 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Mar 9 23:28:22 2009 Subject: Loop unrolling + fusion ? In-Reply-To: References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <84586116-A34E-4980-B5DD-974AAE54DE61@cse.unsw.edu.au> Message-ID: <09592D68-A182-4F85-AC85-A04E6487CEDC@ece.cmu.edu> On 2009 Mar 9, at 9:32, Claus Reinke wrote: > One way out would be to treat the whole mutual recursion as a single > entity, either implicitly, as I indicated, or explicitly, as I > interpret Brandon's somewhat ambiguous comment. In other words, the > peel/unroll limits would apply to a whole group of mutually Sorry, yes, I intended that the unrolling applied explicitly to a group of mutually recursive functions. I'm not sure if the unroll/ peel counts should be multiplied by the number of functions, though. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090309/b72d6359/PGP.bin From marlowsd at gmail.com Tue Mar 10 08:45:36 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 10 08:34:05 2009 Subject: Windows building instructions Message-ID: <49B660F0.4010709@gmail.com> I've made a start on sanitising the Windows building instructions, and generally reoganising the Windows-related stuff in the wiki. Basicalliy my plan is to: - Simplify the instructions. In lots of places we have stuff like "if you get the following bizarre error message ... then do this ...". I'd rather have a set of simple instructions that just work, with a separate (searchable) page for troubleshooting advice. So now we have http://hackage.haskell.org/trac/ghc/wiki/Building/Troubleshooting which is just a list of error messages and solutions, collected from various other places in the docs. If you encounter an error that isn't listed on that page, please add it (guidelines for adding stuff are at the top). - Merge the Windows-specific instructions with the rest of the docs, so we can avoid repetition. So now the instructions for how to set up your Windows system for building GHC are on the main "prerequisites" page: http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites - I've uploaded a set of build tools that work (just MSYS for now) to haskell.org, and linked them from the wiki. This morning I started from a fresh Vista system, installed these tools, and managed to do a complete validate of the GHC HEAD, with 1 test failure. What we still need to do: - Expand the instructions to include Cygwin. I've linked to the existing Cygwin instructions for now, but I think they need simplifying. - Add more common failures and troubleshooting tips. - Merge in contrib docs, e.g. http://hackage.haskell.org/trac/ghc/wiki/ProblemsCompilingGhc I'd be grateful for any help with this - just edit away! Cheers, Simon From ndmitchell at gmail.com Tue Mar 10 09:26:12 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Mar 10 09:14:31 2009 Subject: Windows building instructions In-Reply-To: <49B660F0.4010709@gmail.com> References: <49B660F0.4010709@gmail.com> Message-ID: <404396ef0903100626u53fec256udc8769c806d7bc01@mail.gmail.com> Hi Simon, I got a brand new Vista machine yesterday (and a brand new monitor this morning), running Vista. I'll try out these instructions as soon as its all plugged together. When I had my last stab at compiling GHC I ended up creating a little script to automate some of the common bits and provide basic sanity checking. I've attached the script in case anyone finds it useful. Thanks Neil On Tue, Mar 10, 2009 at 12:45 PM, Simon Marlow wrote: > I've made a start on sanitising the Windows building instructions, and > generally reoganising the Windows-related stuff in the wiki. ?Basicalliy my > plan is to: > > ?- Simplify the instructions. ?In lots of places we have stuff like "if you > ? get the following bizarre error message ... then do this ...". ?I'd > ? rather have a set of simple instructions that just work, with a separate > ? (searchable) page for troubleshooting advice. ?So now we have > > ? http://hackage.haskell.org/trac/ghc/wiki/Building/Troubleshooting > > ? which is just a list of error messages and solutions, collected from > ? various other places in the docs. ?If you encounter an error that isn't > ? listed on that page, please add it (guidelines for adding stuff are at > ? the top). > > ?- Merge the Windows-specific instructions with the rest of the docs, so > ? we can avoid repetition. ?So now the instructions for how to set > ? up your Windows system for building GHC are on the main "prerequisites" > ? page: > > ? http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites > > ?- I've uploaded a set of build tools that work (just MSYS for now) to > ? haskell.org, and linked them from the wiki. ?This morning I started > ? from a fresh Vista system, installed these tools, and managed to > ? do a complete validate of the GHC HEAD, with 1 test failure. > > > What we still need to do: > > ?- Expand the instructions to include Cygwin. ?I've linked to the > ? existing Cygwin instructions for now, but I think they need > ? simplifying. > > ?- Add more common failures and troubleshooting tips. > > ?- Merge in contrib docs, e.g. > > ? http://hackage.haskell.org/trac/ghc/wiki/ProblemsCompilingGhc > > I'd be grateful for any help with this - just edit away! > > Cheers, > ? ? ? ?Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: winbuild.hs Type: application/octet-stream Size: 5641 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090310/04117188/winbuild.obj From simonpj at microsoft.com Tue Mar 10 10:00:58 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Mar 10 09:49:17 2009 Subject: Loop unrolling + fusion ? In-Reply-To: References: <20090228174932.GA23519@whirlpool.galois.com> <49B12BC5.8090008@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C334CB88F1C7@EA-EXMSG-C334.europe.corp.microsoft.com> | What I don't understand yet is the routemap for replacing -fvia-C Good points, Claus. I think the story is as follows: * -fvia-C does not produce much better code, except in exceptionally tight loops, because GHC gives gcc very little scope for optimisation. Simon mentioned something like 1% improvement. * -fvia-C does not give substantially improved portability, because the Evil Mangler must have lots of new (Perl) code for each new platform. (And each new version of gcc changes the details.) * -fvia-C does impose maintenance costs, as this thread has rehearsed. * -fasm has the potential for producing *better* code than gcc, because we can temporarily re-use registers that we must nail down as far as gcc is concerned. | In other words, what is the plan wrt to backends, especially wrt | recovering the optimizations and portability issues previously left to | gcc? I think you may be over-optimistic about the portability and optimisation benefits. As to other back end plans, it's a fairly active place. Ben L is doing great stuff on refactoring the native code back end as part of his Sparc NCG. And John and Norman and I are actively (albeit diverted recently by ICFP submissions) working on getting the refactored STG...flat C-- story into mainstream. Simon From ml at isaac.cedarswampstudios.org Tue Mar 10 10:57:00 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Tue Mar 10 10:45:21 2009 Subject: Reliability of trace? In-Reply-To: References: Message-ID: <200903101057.01047.ml@isaac.cedarswampstudios.org> Colin Paul Adams wrote: > I'm trying to use Debug.Trace to debug some tree-walking that I've > written. > > It seems to me that I am missing some traces on intermediate function > calls. I guess that ghc is re-arranging the code in such a way that > some of these intermediate calls disappear. Anyway of stopping this? I > already specify -O0. right; with -O0 you get pretty much the exact amount of sharing that your code suggests are you sure those traces are attached to expressions that are being evaluated at all? Remember how lazy Haskell is... -Isaac From colin at colina.demon.co.uk Tue Mar 10 11:14:40 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Mar 10 11:03:02 2009 Subject: Reliability of trace? In-Reply-To: <200903101057.01047.ml@isaac.cedarswampstudios.org> (Isaac Dupree's message of "Tue\, 10 Mar 2009 10\:57\:00 -0400") References: <200903101057.01047.ml@isaac.cedarswampstudios.org> Message-ID: >>>>> "Isaac" == Isaac Dupree writes: Isaac> Colin Paul Adams wrote: >> I'm trying to use Debug.Trace to debug some tree-walking that >> I've written. >> >> It seems to me that I am missing some traces on intermediate >> function calls. I guess that ghc is re-arranging the code in >> such a way that some of these intermediate calls >> disappear. Anyway of stopping this? I already specify -O0. Isaac> right; with -O0 you get pretty much the exact amount of Isaac> sharing that your code suggests Isaac> are you sure those traces are attached to expressions that Isaac> are being evaluated at all? Remember how lazy Haskell Isaac> is... I was was absolutely sure of what was happening, I wouldn't need to run a trace :-). But I do know certain things about what is happening, and I cannot see how the code can avoid some of these trace statements. Anyway, I think I know how to fix my code now. When I've done it, I'll put the traces back on, and see if I can understand what is happening. If not, I'll post the code here, and ask the question again, for future enlightenment. -- Colin Adams Preston Lancashire From tuomov at iki.fi Tue Mar 10 14:51:10 2009 From: tuomov at iki.fi (Tuomo Valkonen) Date: Tue Mar 10 14:39:39 2009 Subject: Cygwin version References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> <20090309123640.GC8842@sliver.repetae.net> Message-ID: On 2009-03-09, Tuomo Valkonen wrote: > On 2009-03-09, Tuomo Valkonen wrote: >> On 2009-03-09, John Meacham wrote: >>> perhaps the most recent non-cabalized ghc build might be worth a try. I >>> think darcs still compiles with ghc 6.6, but am not positive., >> >> Mingw-bootstrap, source, or both? > > Tried with both. Got: > > ghc.exe: unknown package: unix With './configure --build=i686-pc-cygwin32 --with-gcc=c:/cygwin/bin/gcc --with-ld=c:/cygwin/bin/ld' I got to the point: ../compiler/ghc-inplace -optc-mno-cygwin -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-fno-strict-aliasing -H16m -O -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c Adjustor.c -o Adjustor.o make: *** [Adjustor.o] Error 1 The stage1 ghc-inplace doesn't seem to be able to produce neither code nor an error message. It just fails. It also isn't a cygwin program according to ldd; should it be? -- "[Fashion] is usually a form of ugliness so intolerable that we have to alter it every six months." -- Oscar Wilde "The computer industry is the only industry that is more fashion-driven than women's fashion." -- RMS From phercek at gmail.com Wed Mar 11 09:19:01 2009 From: phercek at gmail.com (Peter Hercek) Date: Wed Mar 11 09:07:33 2009 Subject: a possibility to redefine built-in GHCi commands In-Reply-To: <49B50854.1040204@gmail.com> References: <49B50854.1040204@gmail.com> Message-ID: Simon Marlow wrote: > Peter Hercek wrote: >> Hi GHCi users, >> >> I would like to be able to redefine the built-in GHCi commands. The >> idea is that when searching for a command the user defined commands >> would be searched first and only then the built-in commands would be >> searched. If user wants to invoke a built-in command regardless of >> user defined commands he/she would need to start it with two colons >> (instead of one). >> >> It is an user interface change which may break some scripts, but it >> would allow to provide different default behavior. >> For example: >> * when I use GhciExt I want all my ":continue" commands to be >> actually ":x :continue" >> * it would allow to specify different order of searching for >> abbreviated commands as the default one >> * it would allow to specify different default switches for builtin >> commands >> >> Would such a change be merged upstream if I would provide a patch? > > Seems reasonable to me. OK, I created a ticket for it and attached the implementation to the ticket. http://hackage.haskell.org/trac/ghc/ticket/3084 Thanks, Peter. From satnams at microsoft.com Wed Mar 11 09:24:47 2009 From: satnams at microsoft.com (Satnam Singh) Date: Wed Mar 11 09:13:26 2009 Subject: ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs Message-ID: Donnie Jones, Simon Marlow and I have been working on infrastructure for logging run-time events and a graphical viewer program called ThreadScope. Hopefully these features will make it into the next release of GHC. We hope the event-log viewer ThreadScope will be useful for the performance tuning of parallel and concurrent Haskell programs. You can see a few screen shots at the program's website http://raintown.org/threadscope Before making the release I thought it would be an idea to ask people what other features people would find useful or performance tuning. So if you have any suggestions please do let us know! Cheers, Satnam Singh ________________________________ Satnam Singh Microsoft 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom Email: satnams@microsoft.com UK tel: +44 1223 479905 Fax: +44 1223 479 999 UK mobile: +44 7979 648412 USA cell: 206 330 1580 USA tel: 206 219 9024 URL: http://research.microsoft.com/~satnams Live Messenger: satnam@raintown.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090311/9f958b66/attachment.htm From marlowsd at gmail.com Wed Mar 11 12:25:21 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Mar 11 12:13:58 2009 Subject: Cygwin version In-Reply-To: References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> <20090309123640.GC8842@sliver.repetae.net> Message-ID: <49B7E5F1.9050307@gmail.com> Tuomo Valkonen wrote: > On 2009-03-09, Tuomo Valkonen wrote: >> On 2009-03-09, Tuomo Valkonen wrote: >>> On 2009-03-09, John Meacham wrote: >>>> perhaps the most recent non-cabalized ghc build might be worth a try. I >>>> think darcs still compiles with ghc 6.6, but am not positive., >>> Mingw-bootstrap, source, or both? >> Tried with both. Got: >> >> ghc.exe: unknown package: unix > > With './configure --build=i686-pc-cygwin32 --with-gcc=c:/cygwin/bin/gcc > --with-ld=c:/cygwin/bin/ld' I got to the point: > > ../compiler/ghc-inplace -optc-mno-cygwin -optc-O -optc-Wall -optc-W > -optc-Wstrict-prototypes -optc-Wmissing-prototypes > -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return > -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel > -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-fno-strict-aliasing > -H16m -O -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint > -c Adjustor.c -o Adjustor.o > make: *** [Adjustor.o] Error 1 > > The stage1 ghc-inplace doesn't seem to be able to produce neither code > nor an error message. It just fails. It also isn't a cygwin program > according to ldd; should it be? You're doing a *port* here, to create a GHC that can generate Cygwin binaries, using a GHC that generates MinGW binaries to bootstrap from. This isn't something you should expect to work out of the box :-) For a start, you should set your platforms like this: build = i386-unknown-mingw32 host = i386-unknown-mingw32 target = i386-unknown-cygwin32 It looks like your stage1 compiler is crashing, but I have no idea why. If you're really interested in getting this working, expect to have to do a lot of hacking in GHC's internals, build system, and libraries. We're here to help, of course. Cheers, Simon From tuomov at iki.fi Wed Mar 11 12:40:33 2009 From: tuomov at iki.fi (Tuomo Valkonen) Date: Wed Mar 11 12:29:01 2009 Subject: Cygwin version References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> <20090309123640.GC8842@sliver.repetae.net> <49B7E5F1.9050307@gmail.com> Message-ID: On 2009-03-11, Simon Marlow wrote: > For a start, you should set your platforms like this: > > build = i386-unknown-mingw32 > host = i386-unknown-mingw32 > target = i386-unknown-cygwin32 "GHC configuration does not support differing host/target (i.e., cross-compiling)" with both the 6.6 and 6.10.1 binaries. Is an existing cross-compiler really necessary? If a stage1 compiler is created in any case, can't it just be made to be a cross-compiler? > If you're really interested in getting this working, expect to have to do a > lot of hacking in GHC's internals, build system, and libraries. We're here > to help, of course. Seems like it will be easier to switch to another version control system. -- Stop Gnomes and other pests! Purchase Windows today! From dons at galois.com Wed Mar 11 12:52:32 2009 From: dons at galois.com (Don Stewart) Date: Wed Mar 11 12:41:41 2009 Subject: Cygwin version In-Reply-To: References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> <20090309123640.GC8842@sliver.repetae.net> <49B7E5F1.9050307@gmail.com> Message-ID: <20090311165232.GF5290@whirlpool.galois.com> tuomov: > On 2009-03-11, Simon Marlow wrote: > > For a start, you should set your platforms like this: > > > > build = i386-unknown-mingw32 > > host = i386-unknown-mingw32 > > target = i386-unknown-cygwin32 > > "GHC configuration does not support differing host/target (i.e., cross-compiling)" > with both the 6.6 and 6.10.1 binaries. > > Is an existing cross-compiler really necessary? If a stage1 compiler is > created in any case, can't it just be made to be a cross-compiler? > > > If you're really interested in getting this working, expect to have to do a > > lot of hacking in GHC's internals, build system, and libraries. We're here > > to help, of course. > > Seems like it will be easier to switch to another version control system. > Have you asked on the darcs-users@ list for a cygwin binary build? I know these are getting pretty rare now, but someone may have already produced one. -- Don From bulat.ziganshin at gmail.com Wed Mar 11 13:01:34 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Mar 11 12:49:59 2009 Subject: Cygwin version In-Reply-To: <20090311165232.GF5290@whirlpool.galois.com> References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> <20090309123640.GC8842@sliver.repetae.net> <49B7E5F1.9050307@gmail.com> <20090311165232.GF5290@whirlpool.galois.com> Message-ID: <1149399315.20090311200134@gmail.com> Hello Don, Wednesday, March 11, 2009, 7:52:32 PM, you wrote: > Have you asked on the darcs-users@ list for a cygwin binary build? I > know these are getting pretty rare now, but someone may have already > produced one. does ghc supports building cygwin executables? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From tuomov at iki.fi Wed Mar 11 13:03:55 2009 From: tuomov at iki.fi (Tuomo Valkonen) Date: Wed Mar 11 12:52:23 2009 Subject: Cygwin version References: <20090308195422.GC24228@whirlpool.galois.com> <20090308224824.GA8842@sliver.repetae.net> <20090309123640.GC8842@sliver.repetae.net> <49B7E5F1.9050307@gmail.com> <20090311165232.GF5290@whirlpool.galois.com> Message-ID: On 2009-03-11, Don Stewart wrote: > Have you asked on the darcs-users@ list for a cygwin binary build? I > know these are getting pretty rare now, but someone may have already > produced one. Yes, to no luck. They thought this was the better place to ask. -- Tuomo From simonpj at microsoft.com Wed Mar 11 18:29:56 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Mar 11 18:18:10 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C334CB99D6FD@EA-EXMSG-C334.europe.corp.microsoft.com> Claus, Max | > My preferred spec would be roughly | > | > {-# NOINLINE f #-} | > as now | > | > {-# INLINE f #-} | > works as now, which is for non-recursive f only (might in future | > be taken as go-ahead for analysis-based recursion unfolding) | > | > {-# INLINE f PEEL n #-} | > inline calls *into* recursive f (called loop peeling for loops) | > | > {-# INLINE f UNROLL m #-} | > inline recursive calls to f *inside* f (called loop unrolling for loops) | > | > {-# INLINE f PEEL n UNROLL m #-} | > combine the previous two Sounds as if you two are evolving a good design, thank you. I am not following the details closely, but I have the advantage of being able to chat to Max directly. Suggestion: if after discussion you think this is a valuable thing to do, write a GHC-Trac-Wiki page describing the design as precisely as possible (eg with examples; I find the above one-liners hard to grok). Along with any major design alternatives. Ideally with a few indicative measurements gotten by by-hand transformations, that show there are real benefits to be had. For implementation, there are two routes. Either totally built-in, or using a Core-to-Core plug-in. The thing I like about the latter is that it can be done without having GHC HQ in the critical path, because we (I) tend to slow things down, being a uniprocesor. We don't have the plug-in capability yet, but I'm encouraging Max to polish it up so that we do. I think it'd be a very valuable facility. Simon From bulat.ziganshin at gmail.com Wed Mar 11 18:36:17 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Mar 11 18:24:43 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C334CB99D6FD@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <43F5CB31DEC84FB8AE68AF6DFD6E27CA@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CB99D6FD@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4410329443.20090312013617@gmail.com> Hello Simon, Thursday, March 12, 2009, 1:29:56 AM, you wrote: > For implementation, there are two routes. Either totally built-in, > or using a Core-to-Core plug-in. The thing I like about the latter > is that it can be done without having GHC HQ in the critical path, > because we (I) tend to slow things down, being a uniprocesor. We > don't have the plug-in capability yet, but I'm encouraging Max to > polish it up so that we do. I think it'd be a very valuable facility. as GHC popularity grows, it may become more profitable to spend resources making it more open, pluggable "compiler factory" rather than doing everything yourself -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Ben.Lippmeier at anu.edu.au Wed Mar 11 20:23:57 2009 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Wed Mar 11 20:12:10 2009 Subject: [Haskell-cafe] ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs In-Reply-To: References: Message-ID: <2E753E6C-E53E-4972-9A23-681B4A61A278@anu.edu.au> Hi Satnam, On 12/03/2009, at 12:24 AM, Satnam Singh wrote: > Before making the release I thought it would be an idea to ask > people what other features people would find useful or performance > tuning. So if you have any suggestions please do let us know! > Is it available in a branch somewhere to try out? Ben. From bbr at informatik.uni-kiel.de Thu Mar 12 09:05:39 2009 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Mar 12 08:53:58 2009 Subject: Bug in deriving Data Typeable? Message-ID: <49B908A3.3050801@informatik.uni-kiel.de> Hi folks, I have been surprised by the derived instances of Data/Typeable when using the combinator ext1Q. First look at the following definition: > useExt1 :: Data a => a -> () > useExt1 = undefined `ext1Q` (\ (Just _) -> ()) > testExt1 :: () > testExt1 = useExt1 (Just ()) As I expected, testExt1 yields () But when I define my own version of Maybe and derive the Data/Typeable instances > data MyMaybe a = MyJust a | MyNothing deriving (Data,Typeable) the corresponding test > useExt1' :: Data a => a -> () > useExt1' = undefined `ext1Q` (\ (MyJust _) -> ()) > testExt1' :: () > testExt1' = useExt1' (MyJust ()) yields *** Exception: Prelude.undefined All of this happens with both ghc 6.10.1 and 6.8.2. Is this a bug in the derived instances, e.g., in dataCast1? If so is there a concise tutorial telling me how to write correct instances for the data type I'm interested in (which is not MyMaybe)? Thanks for your time! Bernd From jpm at cs.uu.nl Thu Mar 12 09:30:52 2009 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Thu Mar 12 09:19:05 2009 Subject: Bug in deriving Data Typeable? In-Reply-To: <49B908A3.3050801@informatik.uni-kiel.de> References: <49B908A3.3050801@informatik.uni-kiel.de> Message-ID: <52f14b210903120630le50a556obe180576e3059af2@mail.gmail.com> Hi Bernd, I guess this might be the same issue reported some time ago ( http://thread.gmane.org/gmane.comp.lang.haskell.generics/53/focus=54): the derived instances of Data do not define dataCast1. If you define your own instance of Data for MyMaybe and add the definition of dataCast1 you will get the expected behavior. Cheers, Pedro On Thu, Mar 12, 2009 at 14:05, Bernd Brassel wrote: > Hi folks, > > I have been surprised by the derived instances of Data/Typeable when > using the combinator ext1Q. First look at the following definition: > > > useExt1 :: Data a => a -> () > > useExt1 = undefined `ext1Q` (\ (Just _) -> ()) > > > testExt1 :: () > > testExt1 = useExt1 (Just ()) > > As I expected, testExt1 yields () > > But when I define my own version of Maybe and derive the Data/Typeable > instances > > > data MyMaybe a = MyJust a | MyNothing deriving (Data,Typeable) > > the corresponding test > > > useExt1' :: Data a => a -> () > > useExt1' = undefined `ext1Q` (\ (MyJust _) -> ()) > > > testExt1' :: () > > testExt1' = useExt1' (MyJust ()) > > yields *** Exception: Prelude.undefined > > All of this happens with both ghc 6.10.1 and 6.8.2. > > Is this a bug in the derived instances, e.g., in dataCast1? If so is > there a concise tutorial telling me how to write correct instances for > the data type I'm interested in (which is not MyMaybe)? > > Thanks for your time! > Bernd > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090312/d90d535c/attachment.htm From marlowsd at gmail.com Thu Mar 12 10:42:42 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Mar 12 10:31:10 2009 Subject: [Haskell-cafe] ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs In-Reply-To: <2E753E6C-E53E-4972-9A23-681B4A61A278@anu.edu.au> References: <2E753E6C-E53E-4972-9A23-681B4A61A278@anu.edu.au> Message-ID: <49B91F62.8030706@gmail.com> Ben Lippmeier wrote: > > On 12/03/2009, at 12:24 AM, Satnam Singh wrote: >> Before making the release I thought it would be an idea to ask people >> what other features people would find useful or performance tuning. So >> if you have any suggestions please do let us know! >> > > Is it available in a branch somewhere to try out? There are three parts to it: - some patches to GHC to generate the log files. The patches are not yet in, but I hope to get them in in the next couple of weeks. - a Haskell library for parsing the log files. This will be up on Hackage soon. You can use this to write your own analysis tools, visualisers, or whatever. - The ThreadScope viewer itself, which will also be up on Hackage as soon as its ready. So we fully intend to get this out there ASAP, although until GHC 6.12 is released you will need to use a GHC snapshot to generate the log files. Cheers, Simon From bbr at informatik.uni-kiel.de Thu Mar 12 12:02:26 2009 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Mar 12 11:50:49 2009 Subject: Bug in deriving Data Typeable? In-Reply-To: <52f14b210903120630le50a556obe180576e3059af2@mail.gmail.com> References: <49B908A3.3050801@informatik.uni-kiel.de> <52f14b210903120630le50a556obe180576e3059af2@mail.gmail.com> Message-ID: <49B93212.7040207@informatik.uni-kiel.de> Jos? Pedro Magalh?es wrote: > Hi Bernd, > > I guess this might be the same issue reported some time ago ( > http://thread.gmane.org/gmane.comp.lang.haskell.generics/53/focus=54): the > derived instances of Data do not define dataCast1. If you define your own > instance of Data for MyMaybe and add the definition of dataCast1 you will > get the expected behavior. Your link pointed me in the right direction to fix the bug for my application. Many thanks! Did you submit a bug report? From dons at galois.com Thu Mar 12 12:37:46 2009 From: dons at galois.com (Don Stewart) Date: Thu Mar 12 12:27:06 2009 Subject: [Haskell-cafe] ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs In-Reply-To: <49B91F62.8030706@gmail.com> References: <2E753E6C-E53E-4972-9A23-681B4A61A278@anu.edu.au> <49B91F62.8030706@gmail.com> Message-ID: <20090312163746.GB10693@whirlpool.galois.com> marlowsd: > Ben Lippmeier wrote: > >> >> On 12/03/2009, at 12:24 AM, Satnam Singh wrote: >>> Before making the release I thought it would be an idea to ask people >>> what other features people would find useful or performance tuning. >>> So if you have any suggestions please do let us know! >>> >> >> Is it available in a branch somewhere to try out? > > There are three parts to it: > > - some patches to GHC to generate the log files. The patches are > not yet in, but I hope to get them in in the next couple of weeks. Just as a meta-point, it makes a *lot* of sense for the runtime to support proper logging -- it's practically a microkernel after all, so logging makes as much sense for GHC's rts as it does for regular kernels. Now we just need a /proc for the rts, so I can peek at GC stats live. > - a Haskell library for parsing the log files. This will be up > on Hackage soon. You can use this to write your own analysis > tools, visualisers, or whatever. > > - The ThreadScope viewer itself, which will also be up on Hackage > as soon as its ready. > > So we fully intend to get this out there ASAP, although until GHC 6.12 is > released you will need to use a GHC snapshot to generate the log files. Sweet. This should have many many applications for work projects ... "attach a viewer to a remote Haskell server to see what's it's up to"... "heartbeat monitoring of the rts" ... -- Don From karel.gardas at centrum.cz Thu Mar 12 14:00:23 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu Mar 12 13:48:27 2009 Subject: [Haskell-cafe] ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs In-Reply-To: <20090312163746.GB10693@whirlpool.galois.com> References: <2E753E6C-E53E-4972-9A23-681B4A61A278@anu.edu.au> <49B91F62.8030706@gmail.com> <20090312163746.GB10693@whirlpool.galois.com> Message-ID: <49B94DB7.7080009@centrum.cz> Don Stewart wrote: > marlowsd: >> Ben Lippmeier wrote: >> >>> On 12/03/2009, at 12:24 AM, Satnam Singh wrote: >>>> Before making the release I thought it would be an idea to ask people >>>> what other features people would find useful or performance tuning. >>>> So if you have any suggestions please do let us know! >>>> >>> Is it available in a branch somewhere to try out? >> There are three parts to it: >> >> - some patches to GHC to generate the log files. The patches are >> not yet in, but I hope to get them in in the next couple of weeks. > > Just as a meta-point, it makes a *lot* of sense for the runtime to > support proper logging -- it's practically a microkernel after all, so > logging makes as much sense for GHC's rts as it does for regular > kernels. > > Now we just need a /proc for the rts, so I can peek at GC stats live. Seeing this thread and discussion direction I cannot resist to temptation to ask: is anybody going to write rts DTrace[1] provider? Thanks, Karel [1]: http://en.wikipedia.org/wiki/DTrace From dons at galois.com Thu Mar 12 14:00:28 2009 From: dons at galois.com (Don Stewart) Date: Thu Mar 12 13:51:41 2009 Subject: [Haskell-cafe] ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs In-Reply-To: <49B94DB7.7080009@centrum.cz> References: <2E753E6C-E53E-4972-9A23-681B4A61A278@anu.edu.au> <49B91F62.8030706@gmail.com> <20090312163746.GB10693@whirlpool.galois.com> <49B94DB7.7080009@centrum.cz> Message-ID: <20090312180028.GG10693@whirlpool.galois.com> karel.gardas: > Don Stewart wrote: > > marlowsd: > >> Ben Lippmeier wrote: > >> > >>> On 12/03/2009, at 12:24 AM, Satnam Singh wrote: > >>>> Before making the release I thought it would be an idea to ask people > >>>> what other features people would find useful or performance tuning. > >>>> So if you have any suggestions please do let us know! > >>>> > >>> Is it available in a branch somewhere to try out? > >> There are three parts to it: > >> > >> - some patches to GHC to generate the log files. The patches are > >> not yet in, but I hope to get them in in the next couple of weeks. > > > > Just as a meta-point, it makes a *lot* of sense for the runtime to > > support proper logging -- it's practically a microkernel after all, so > > logging makes as much sense for GHC's rts as it does for regular > > kernels. > > > > Now we just need a /proc for the rts, so I can peek at GC stats live. > > Seeing this thread and discussion direction I cannot resist to > temptation to ask: is anybody going to write rts DTrace[1] provider? I think this is clear next step in the investigations. -- Don From jpm at cs.uu.nl Fri Mar 13 04:49:30 2009 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Fri Mar 13 04:37:40 2009 Subject: Bug in deriving Data Typeable? In-Reply-To: <49B93212.7040207@informatik.uni-kiel.de> References: <49B908A3.3050801@informatik.uni-kiel.de> <52f14b210903120630le50a556obe180576e3059af2@mail.gmail.com> <49B93212.7040207@informatik.uni-kiel.de> Message-ID: <52f14b210903130149n4ddb2565icac00deb1efefb25@mail.gmail.com> Hello, On Thu, Mar 12, 2009 at 17:02, Bernd Brassel wrote: > Jos? Pedro Magalh?es wrote: > > Hi Bernd, > > > > I guess this might be the same issue reported some time ago ( > > http://thread.gmane.org/gmane.comp.lang.haskell.generics/53/focus=54): > the > > derived instances of Data do not define dataCast1. If you define your own > > instance of Data for MyMaybe and add the definition of dataCast1 you will > > get the expected behavior. > > Your link pointed me in the right direction to fix the bug for my > application. Many thanks! Did you submit a bug report? > > Now I did: http://hackage.haskell.org/trac/ghc/ticket/3087 Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090313/14710d0d/attachment.htm From choener at tbi.univie.ac.at Fri Mar 13 10:20:30 2009 From: choener at tbi.univie.ac.at (Christian Hoener zu Siederdissen) Date: Fri Mar 13 10:08:48 2009 Subject: Control.Parallel.Strategies.parMap CPU usage Message-ID: <49BA6BAE.8040407@tbi.univie.ac.at> Greetings, when using parMap (or parList and demanding) I see a curious pattern in CPU usage. Running "parMap rnf fib [1..100]" gives the following pattern of used CPUs: 4,3,2,1,4,3,2,1,... The fib function requires roughly two times the time if we go from fib(n) to fib(n+1), meaning that calculating the next element in the list always takes longer than the current. What I would like is a version of parMap that directly takes a free CPU and lets it calculate the next result, giving the usage pattern 4,4,4,4,... Below you find the simple Haskell program, which gives these results, please compile with "ghc --make -threaded -O2 Para.hs" and run on a machine with at least two cores and "./Para +RTS -N2" or better. I am not filing a bug yet as I would prefer to be told that I did it wrong and here is a better way: ... Thanks, Christian (Please assume that later on, "fib" will be replaced by something meaningful ;) # ghc --version # The Glorious Glasgow Haskell Compilation System, version 6.10.1 module Main where import Control.Parallel.Strategies -- parallel computation of fibonacci numbers in slow fib :: Int -> Int fib n | n < 1 = error "n < 1" | n == 1 = 1 | n == 2 = 1 | otherwise = fib (n-1) + fib(n-2) fibs = parMap rnf fib $ [1..100] -- fibs = let fs = map fib $ [1..100] in fs `demanding` (parList rnf fs) main = do mapM_ (putStrLn . show) $ zip [1..] fibs From marlowsd at gmail.com Fri Mar 13 10:47:17 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Mar 13 10:35:32 2009 Subject: Control.Parallel.Strategies.parMap CPU usage In-Reply-To: <49BA6BAE.8040407@tbi.univie.ac.at> References: <49BA6BAE.8040407@tbi.univie.ac.at> Message-ID: <49BA71F5.5020107@gmail.com> Christian Hoener zu Siederdissen wrote: > when using parMap (or parList and demanding) I see a curious pattern in > CPU usage. > Running "parMap rnf fib [1..100]" gives the following pattern of used CPUs: > 4,3,2,1,4,3,2,1,... How did you find out which CPU is being used? > The fib function requires roughly two times the time if we go from > fib(n) to fib(n+1), meaning that calculating the next element in the > list always takes longer than the current. What I would like is a > version of parMap that directly takes a free CPU and lets it calculate > the next result, giving the usage pattern 4,4,4,4,... In GHC you don't have any control over which CPU is used to execute a spark. We use dynamic load-balancing, which means the work distribution is essentially random, and will change from run to run. If you want more explicit control over your work distribution, try using GHC.Conc.forkOnIO. Also note that the implementation of much of this stuff is changing rapidly, so you might want to try a recent snapshot. Take a look at our paper, if you haven't already: http://www.haskell.org/~simonmar/papers/multicore-ghc.pdf Cheers, Simon From choener at tbi.univie.ac.at Fri Mar 13 11:02:27 2009 From: choener at tbi.univie.ac.at (Christian Hoener zu Siederdissen) Date: Fri Mar 13 10:50:45 2009 Subject: Control.Parallel.Strategies.parMap CPU usage In-Reply-To: <49BA71F5.5020107@gmail.com> References: <49BA6BAE.8040407@tbi.univie.ac.at> <49BA71F5.5020107@gmail.com> Message-ID: <49BA7583.8070108@tbi.univie.ac.at> Simon Marlow wrote: > Christian Hoener zu Siederdissen wrote: > >> when using parMap (or parList and demanding) I see a curious pattern >> in CPU usage. >> Running "parMap rnf fib [1..100]" gives the following pattern of used >> CPUs: >> 4,3,2,1,4,3,2,1,... > > How did you find out which CPU is being used? Sorry for the misunderstanding, the "pattern of used CPUs" is the _counted_number_ of active cores! That means that I am cycling through 4 to 1 active CPUs while there definitively is work that could be done by a core. Essentially, parMap seems to divide the list of thunks into blocks of 4 (or n in -Nn) and finishes each block before going to the next block. This is easy to see by running the program and watching the number of active threads in htop / top. > >> The fib function requires roughly two times the time if we go from >> fib(n) to fib(n+1), meaning that calculating the next element in the >> list always takes longer than the current. What I would like is a >> version of parMap that directly takes a free CPU and lets it calculate >> the next result, giving the usage pattern 4,4,4,4,... > > In GHC you don't have any control over which CPU is used to execute a > spark. We use dynamic load-balancing, which means the work distribution > is essentially random, and will change from run to run. > > If you want more explicit control over your work distribution, try using > GHC.Conc.forkOnIO. > > Also note that the implementation of much of this stuff is changing > rapidly, so you might want to try a recent snapshot. Take a look at our > paper, if you haven't already: > > http://www.haskell.org/~simonmar/papers/multicore-ghc.pdf > > Cheers, > Simon Hopefully I will find the time to try the latest head and see if the idle-pattern (better name?) persists. Gruss, Christian From conal at conal.net Sun Mar 15 02:43:32 2009 From: conal at conal.net (Conal Elliott) Date: Sun Mar 15 02:31:37 2009 Subject: ghci finding include files exported from other packages? Message-ID: The applicative-numbers package [1] provides an include file. With ghci, the include file isn't being found, though with cabal+ghc it is found. My test source is just two lines: {-# LANGUAGE CPP #-} #include "ApplicativeNumeric-inc.hs" I'd sure appreciate it if someone could take a look at the .cabal file [2] and tell me if I'm doing something wrong. And/or point me to one or more working examples of cabal packages that export include files that are then findable via ghci. - Conal [1] http://hackage.haskell.org/packages/archive/applicative-numbers [2] http://hackage.haskell.org/packages/archive/applicative-numbers/0.0.2/applicative-numbers.cabal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090314/33383349/attachment.htm From duncan.coutts at worc.ox.ac.uk Sun Mar 15 08:27:48 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 15 08:15:53 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: References: Message-ID: <1237120068.22402.515.camel@localhost> On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote: > The applicative-numbers package [1] provides an include file. With > ghci, the include file isn't being found, though with cabal+ghc it is > found. > > My test source is just two lines: > > {-# LANGUAGE CPP #-} > #include "ApplicativeNumeric-inc.hs" > > I'd sure appreciate it if someone could take a look at the .cabal file > [2] and tell me if I'm doing something wrong. And/or point me to one > or more working examples of cabal packages that export include files > that are then findable via ghci. This sounds like a chicken and egg problem. To know which package include directories to use GHCi needs to know which packages your module uses. However to work out which packages it needs it has to load the module which means pre-processing it! With cabal we get round this problem because Cabal calls ghc with -package this -package that etc and so when ghc cpp's the module it does know which package include directories to look in. So if you did ghci -package applicative-numbers then it should work. I'm afraid I don't have any good suggestion for how to make it work with ghci without having to specify any options at all. Duncan From igloo at earth.li Sun Mar 15 11:51:42 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Mar 15 11:39:45 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 Message-ID: <20090315155142.GA18000@matrix.chaos.earth.li> We are pleased to announce the first release candidate for GHC 6.10.2: http://www.haskell.org/ghc/dist/6.10.2-rc1/ This includes two source bundles: ghc-6.10.1.20090314-src.tar.bz2 ghc-6.10.1.20090314-src-extralibs.tar.bz2 Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There are also installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team From loganathan.lingappan at intel.com Sun Mar 15 11:59:54 2009 From: loganathan.lingappan at intel.com (Lingappan, Loganathan) Date: Sun Mar 15 11:47:31 2009 Subject: Link errors Message-ID: Hi, If I include import Text.Regex.Posix ((=~)) into a Haskell code, I get the following link error: FindBBUsage.o:fake:(.text+0x44d): undefined reference to `__stginit_regexzmposixzm0zi72zi0zi3_TextziRegexziPosix_' collect2: ld returned 1 exit status Any ideas on how to fix this? I am using GHC version 6.10.1 on Windows XP. Thanks, Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090315/ec30060e/attachment.htm From allbery at ece.cmu.edu Sun Mar 15 12:12:30 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Mar 15 12:00:49 2009 Subject: Link errors In-Reply-To: References: Message-ID: <2748A1B7-36F8-4B51-B5F9-E29DEC674410@ece.cmu.edu> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090315/2f17c84a/PGP.bin From conal at conal.net Sun Mar 15 12:13:35 2009 From: conal at conal.net (Conal Elliott) Date: Sun Mar 15 12:01:37 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: <1237120068.22402.515.camel@localhost> References: <1237120068.22402.515.camel@localhost> Message-ID: That did it. I've added ":set -package applicative-numbers" to my .ghci and am back in business. Thanks! IIUC, there's an inconsistency in ghci's treatment of modules vs include files, in that modules will be found without -package, but include files won't. Room for improvement, perhaps. - Conal On Sun, Mar 15, 2009 at 5:27 AM, Duncan Coutts wrote: > On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote: > > The applicative-numbers package [1] provides an include file. With > > ghci, the include file isn't being found, though with cabal+ghc it is > > found. > > > > My test source is just two lines: > > > > {-# LANGUAGE CPP #-} > > #include "ApplicativeNumeric-inc.hs" > > > > I'd sure appreciate it if someone could take a look at the .cabal file > > [2] and tell me if I'm doing something wrong. And/or point me to one > > or more working examples of cabal packages that export include files > > that are then findable via ghci. > > This sounds like a chicken and egg problem. To know which package > include directories to use GHCi needs to know which packages your module > uses. However to work out which packages it needs it has to load the > module which means pre-processing it! > > With cabal we get round this problem because Cabal calls ghc with > -package this -package that etc and so when ghc cpp's the module it does > know which package include directories to look in. > > So if you did ghci -package applicative-numbers then it should work. I'm > afraid I don't have any good suggestion for how to make it work with > ghci without having to specify any options at all. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090315/c885640c/attachment-0001.htm From loganathan.lingappan at intel.com Sun Mar 15 12:15:57 2009 From: loganathan.lingappan at intel.com (Lingappan, Loganathan) Date: Sun Mar 15 12:03:43 2009 Subject: Link errors In-Reply-To: <2748A1B7-36F8-4B51-B5F9-E29DEC674410@ece.cmu.edu> References: <2748A1B7-36F8-4B51-B5F9-E29DEC674410@ece.cmu.edu> Message-ID: Great! This works! Thanks a lot, Logo ________________________________ From: Brandon S. Allbery KF8NH [mailto:allbery@ece.cmu.edu] Sent: Sunday, March 15, 2009 6:13 PM To: Lingappan, Loganathan Cc: Brandon S. Allbery KF8NH; glasgow-haskell-users@haskell.org Subject: Re: Link errors On 2009 Mar 15, at 11:59, Lingappan, Loganathan wrote: FindBBUsage.o:fake:(.text+0x44d): undefined reference to `__stginit_regexzmposixzm0zi72zi0zi3_TextziRegexziPosix_' collect2: ld returned 1 exit status Either use "ghc --make" or "ghc -package regex-posix". The former is preferred. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090315/daf5fd66/attachment.htm From duncan.coutts at worc.ox.ac.uk Sun Mar 15 17:34:47 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Mar 15 17:23:00 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: References: <1237120068.22402.515.camel@localhost> Message-ID: <1237152887.22402.524.camel@localhost> On Sun, 2009-03-15 at 09:13 -0700, Conal Elliott wrote: > That did it. I've added ":set -package applicative-numbers" to > my .ghci and am back in business. Thanks! > > IIUC, there's an inconsistency in ghci's treatment of modules vs > include files, in that modules will be found without -package, but > include files won't. Room for improvement, perhaps. But that's because of the circularity I described. GHC can chase Haskell imports because it can parse Haskell, but chasing CPP #includes would require us to re-implement cpp. Perhaps we could do it by modifying cpphs. Duncan From conal at conal.net Sun Mar 15 18:46:46 2009 From: conal at conal.net (Conal Elliott) Date: Sun Mar 15 18:34:47 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: <1237152887.22402.524.camel@localhost> References: <1237120068.22402.515.camel@localhost> <1237152887.22402.524.camel@localhost> Message-ID: Thanks for the clarification, Duncan. Seems an easy partial solution would be a single pass (before CPP) that notices just the #include directives. Consult the package database to find those packages. That route would find direct includes but not indirect ones. An optional and still-easy next step would be to look inside those includes for further #include directives. I'm unsure whether the cabal solution is as powerful as the single-level include method or the recursive one. - Conal On Sun, Mar 15, 2009 at 2:34 PM, Duncan Coutts wrote: > On Sun, 2009-03-15 at 09:13 -0700, Conal Elliott wrote: > > That did it. I've added ":set -package applicative-numbers" to > > my .ghci and am back in business. Thanks! > > > > IIUC, there's an inconsistency in ghci's treatment of modules vs > > include files, in that modules will be found without -package, but > > include files won't. Room for improvement, perhaps. > > But that's because of the circularity I described. GHC can chase Haskell > imports because it can parse Haskell, but chasing CPP #includes would > require us to re-implement cpp. Perhaps we could do it by modifying > cpphs. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090315/0a2dcced/attachment.htm From ingmar at exherbo.org Sun Mar 15 18:49:20 2009 From: ingmar at exherbo.org (Ingmar Vanhassel) Date: Sun Mar 15 18:37:21 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090315155142.GA18000@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> Message-ID: <20090315224920.GA23101@bach> On Sun, Mar 15, 2009 at 03:51:42PM +0000, Ian Lynagh wrote: > > We are pleased to announce the first release candidate for GHC 6.10.2: > > http://www.haskell.org/ghc/dist/6.10.2-rc1/ > > This includes two source bundles: > > ghc-6.10.1.20090314-src.tar.bz2 > ghc-6.10.1.20090314-src-extralibs.tar.bz2 Could you add a testsuite tarball too please? -- Exherbo KDE, X.org maintainer From igloo at earth.li Sun Mar 15 19:53:27 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Mar 15 19:41:29 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090315224920.GA23101@bach> References: <20090315155142.GA18000@matrix.chaos.earth.li> <20090315224920.GA23101@bach> Message-ID: <20090315235327.GA21375@matrix.chaos.earth.li> On Sun, Mar 15, 2009 at 10:49:20PM +0000, Ingmar Vanhassel wrote: > > > > http://www.haskell.org/ghc/dist/6.10.2-rc1/ > > Could you add a testsuite tarball too please? There's already one there. Thanks Ian From kolmodin at dtek.chalmers.se Mon Mar 16 03:34:12 2009 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Mon Mar 16 03:22:40 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090315155142.GA18000@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> Message-ID: <49BE00F4.2030004@dtek.chalmers.se> Ian Lynagh wrote: > We are pleased to announce the first release candidate for GHC 6.10.2: > > http://www.haskell.org/ghc/dist/6.10.2-rc1/ > > This includes two source bundles: > > ghc-6.10.1.20090314-src.tar.bz2 > ghc-6.10.1.20090314-src-extralibs.tar.bz2 Awesome! This release candidate is also available for testing purposes through the gentoo haskell overlay. http://code.haskell.org/gentoo/gentoo-haskell/ You can use the overlay either through layman (overlay called haskell) http://www.gentoo.org/proj/en/overlays/userguide.xml or by yourself a la old school, PORTDIR_OVERLAY in make.conf. We don't yet have any ebuilds for the extralibs. GHC is hard masked, meaning only available for testing purposes, use caution :) $ echo dev-lang/ghc >> /etc/portage/package.unmask It's also keyworded ~amd64 ~x86, meaning you'll have to allow potentially unstable packages: $ echo dev-lang/ghc >> /etc/portage/package.keywords Last but not least, the ebuild does not provide any bootstrapping binary to compile ghc, so you need to already have a version of ghc installed to bootstrap with. Then emerge with $ USE="ghcbootstrap -binary" emerge dev-lang/ghc Please report any issues in #gentoo-haskell @ freenode. Cheers, Lennart Kolmodin -- Gentoo Dev From karel.gardas at centrum.cz Mon Mar 16 06:26:05 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon Mar 16 06:13:50 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090315155142.GA18000@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> Message-ID: <49BE293D.9020709@centrum.cz> Hello, interesting but I'm not able to build this on SunOS 5.11/x86. The build fails with: (echo dist/build/cbits/PrelIOUtils.p_o dist/build/cbits/WCsubst.p_o dist/build/cbits/Win32Utils.p_o dist/build/cbits/consUtils.p_o dist/build/cbits/dirUtils.p_o dist/build/cbits/inputReady.p_o dist/build/cbits/selectUtils.p_o `find dist/build -name "*_stub.p_o" -print`; find dist/build/Foreign/Concurrent_split dist/build/GHC/Arr_split dist/build/GHC/Base_split dist/build/GHC/Classes_split dist/build/GHC/Conc_split dist/build/GHC/ConsoleHandler_split dist/build/GHC/Desugar_split dist/build/GHC/Enum_split dist/build/GHC/Environment_split dist/build/GHC/Err_split dist/build/GHC/Exception_split dist/build/GHC/Exts_split dist/build/GHC/Float_split dist/build/GHC/ForeignPtr_split dist/build/GHC/Handle_split dist/build/GHC/IO_split dist/build/GHC/IOBase_split dist/build/GHC/Int_split dist/build/GHC/List_split dist/build/GHC/Num_split dist/build/GHC/PArr_split dist/build/GHC/Pack_split dist/build/GHC/Ptr_split dist/build/GHC/Read_split dist/build/GHC/Real_split dist/build/GHC/ST_split dist/build/GHC/STRef_split dist/build/GHC/Show_split dist/build/GHC/Stable_split dist/build/GHC/Storable_split dist/build/GHC/TopHandler_split dist/build/GHC/Unicode_split dist/build/GHC/Weak_split dist/build/GHC/Word_split dist/build/System/Timeout_split dist/build/Control/Applicative_split dist/build/Control/Arrow_split dist/build/Control/Category_split dist/build/Control/Concurrent_split dist/build/Control/Concurrent/Chan_split dist/build/Control/Concurrent/MVar_split dist/build/Control/Concurrent/QSem_split dist/build/Control/Concurrent/QSemN_split dist/build/Control/Concurrent/SampleVar_split dist/build/Control/Exception_split dist/build/Control/Exception/Base_split dist/build/Control/OldException_split dist/build/Control/Monad_split dist/build/Control/Monad/Fix_split dist/build/Control/Monad/Instances_split dist/build/Control/Monad/ST_split dist/build/Control/Monad/ST/Lazy_split dist/build/Control/Monad/ST/Strict_split dist/build/Data/Bits_split dist/build/Data/Bool_split dist/build/Data/Char_split dist/build/Data/Complex_split dist/build/Data/Dynamic_split dist/build/Data/Either_split dist/build/Data/Eq_split dist/build/Data/Data_split dist/build/Data/Fixed_split dist/build/Data/Foldable_split dist/build/Data/Function_split dist/build/Data/HashTable_split dist/build/Data/IORef_split dist/build/Data/Int_split dist/build/Data/Ix_split dist/build/Data/List_split dist/build/Data/Maybe_split dist/build/Data/Monoid_split dist/build/Data/Ord_split dist/build/Data/Ratio_split dist/build/Data/STRef_split dist/build/Data/STRef/Lazy_split dist/build/Data/STRef/Strict_split dist/build/Data/String_split dist/build/Data/Traversable_split dist/build/Data/Tuple_split dist/build/Data/Typeable_split dist/build/Data/Unique_split dist/build/Data/Version_split dist/build/Data/Word_split dist/build/Debug/Trace_split dist/build/Foreign_split dist/build/Foreign/C_split dist/build/Foreign/C/Error_split dist/build/Foreign/C/String_split dist/build/Foreign/C/Types_split dist/build/Foreign/ForeignPtr_split dist/build/Foreign/Marshal_split dist/build/Foreign/Marshal/Alloc_split dist/build/Foreign/Marshal/Array_split dist/build/Foreign/Marshal/Error_split dist/build/Foreign/Marshal/Pool_split dist/build/Foreign/Marshal/Utils_split dist/build/Foreign/Ptr_split dist/build/Foreign/StablePtr_split dist/build/Foreign/Storable_split dist/build/Numeric_split dist/build/Prelude_split dist/build/System/Console/GetOpt_split dist/build/System/CPUTime_split dist/build/System/Environment_split dist/build/System/Exit_split dist/build/System/IO_split dist/build/System/IO/Error_split dist/build/System/IO/Unsafe_split dist/build/System/Info_split dist/build/System/Mem_split dist/build/System/Mem/StableName_split dist/build/System/Mem/Weak_split dist/build/System/Posix/Internals_split dist/build/System/Posix/Types_split dist/build/Text/ParserCombinators/ReadP_split dist/build/Text/ParserCombinators/ReadPrec_split dist/build/Text/Printf_split dist/build/Text/Read_split dist/build/Text/Read/Lex_split dist/build/Text/Show_split dist/build/Text/Show/Functions_split dist/build/Unsafe/Coerce_split -name '*.p_o' -print) | xargs /usr/bin/ar q dist/build/libHSbase-4.1.0.0_p.a ar: creating dist/build/libHSbase-4.1.0.0_p.a internal error: error_message(58) gmake[3]: *** [dist/build/libHSbase-4.1.0.0_p.a] Error 100 gmake[2]: *** [all] Error 1 gmake[2]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries/base' gmake[1]: *** [make.library.base] Error 2 gmake[1]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries' gmake: *** [stage1] Error 2 I've configure with simple: ./configure --prefix=/tmp/ghc-6.10.1.20090314 and build with: gmake The interesting thing is that GHC stable builds on my buildbot well: http://darcs.haskell.org/buildbot/all/builders/kgardas%20stable Any idea what I'm doing wrong? Thanks, Karel From marlowsd at gmail.com Mon Mar 16 08:13:07 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Mar 16 08:01:15 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: <1237120068.22402.515.camel@localhost> References: <1237120068.22402.515.camel@localhost> Message-ID: <49BE4253.20808@gmail.com> Duncan Coutts wrote: > On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote: >> The applicative-numbers package [1] provides an include file. With >> ghci, the include file isn't being found, though with cabal+ghc it is >> found. >> >> My test source is just two lines: >> >> {-# LANGUAGE CPP #-} >> #include "ApplicativeNumeric-inc.hs" >> >> I'd sure appreciate it if someone could take a look at the .cabal file >> [2] and tell me if I'm doing something wrong. And/or point me to one >> or more working examples of cabal packages that export include files >> that are then findable via ghci. > > This sounds like a chicken and egg problem. To know which package > include directories to use GHCi needs to know which packages your module > uses. However to work out which packages it needs it has to load the > module which means pre-processing it! > > With cabal we get round this problem because Cabal calls ghc with > -package this -package that etc and so when ghc cpp's the module it does > know which package include directories to look in. Perhaps I'm missing something, but if applicative-numbers is an exposed package, shouldn't we be adding its include-dirs when invoking CPP? Cheers, Simon From Christian.Maeder at dfki.de Mon Mar 16 11:00:09 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Mar 16 10:48:10 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090315155142.GA18000@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> Message-ID: <49BE6979.9030304@dfki.de> Ian Lynagh wrote: > We are pleased to announce the first release candidate for GHC 6.10.2: > > http://www.haskell.org/ghc/dist/6.10.2-rc1/ Under Solaris grep does not understand "-q" in configure: checkMake380() { if $1 --version 2>&1 | head -1 | grep -q 'GNU Make 3\.80' it fails with: grep: illegal option -- q Usage: grep -hblcnsviw pattern file . . . grep: illegal option -- q Usage: grep -hblcnsviw pattern file . . . C. From mechvel at botik.ru Mon Mar 16 13:43:25 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Mar 16 13:36:02 2009 Subject: testing 6.10.2-candidate Message-ID: <20090316174325.GA16997@scico.botik.ru> I have tested ghc-6.10.1.20090314 on Debian Linux, i386-unknown, on making from source by ghc-6.10.1, making itself from source, DoCon. It looks all right. ----------------- Serge Mechveliani mechvel@botik.ru From duncan.coutts at worc.ox.ac.uk Mon Mar 16 17:47:31 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 16 17:35:40 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: <49BE4253.20808@gmail.com> References: <1237120068.22402.515.camel@localhost> <49BE4253.20808@gmail.com> Message-ID: <1237240051.22402.529.camel@localhost> On Mon, 2009-03-16 at 12:13 +0000, Simon Marlow wrote: > > This sounds like a chicken and egg problem. To know which package > > include directories to use GHCi needs to know which packages your module > > uses. However to work out which packages it needs it has to load the > > module which means pre-processing it! > > > > With cabal we get round this problem because Cabal calls ghc with > > -package this -package that etc and so when ghc cpp's the module it does > > know which package include directories to look in. > > Perhaps I'm missing something, but if applicative-numbers is an exposed > package, shouldn't we be adding its include-dirs when invoking CPP? Yes, if we know we're using it. If we specify -package blah on the command line then we do know we're using it and everything works (because ghc uses the include-dirs when it calls cpp). If we don't specify -package then ghc does not know we need the package until after import chasing is done. Import chasing requires that we run cpp on the .hs file first and that brings us full circle. Duncan From conal at conal.net Mon Mar 16 19:04:42 2009 From: conal at conal.net (Conal Elliott) Date: Mon Mar 16 18:52:40 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: <1237240051.22402.529.camel@localhost> References: <1237120068.22402.515.camel@localhost> <49BE4253.20808@gmail.com> <1237240051.22402.529.camel@localhost> Message-ID: On Mon, Mar 16, 2009 at 2:47 PM, Duncan Coutts wrote: > On Mon, 2009-03-16 at 12:13 +0000, Simon Marlow wrote: > > > > This sounds like a chicken and egg problem. To know which package > > > include directories to use GHCi needs to know which packages your > module > > > uses. However to work out which packages it needs it has to load the > > > module which means pre-processing it! > > > > > > With cabal we get round this problem because Cabal calls ghc with > > > -package this -package that etc and so when ghc cpp's the module it > does > > > know which package include directories to look in. > > > > Perhaps I'm missing something, but if applicative-numbers is an exposed > > package, shouldn't we be adding its include-dirs when invoking CPP? > > Yes, if we know we're using it. If we specify -package blah on the > command line then we do know we're using it and everything works > (because ghc uses the include-dirs when it calls cpp). If we don't > specify -package then ghc does not know we need the package until after > import chasing is done. Import chasing requires that we run cpp on > the .hs file first and that brings us full circle. > > Duncan Unless you drop the cpp-first requirement and have import-chasing look into #include'd files, as I described earlier. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090316/f7905410/attachment.htm From duncan.coutts at worc.ox.ac.uk Mon Mar 16 19:17:45 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 16 19:05:45 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: References: <1237120068.22402.515.camel@localhost> <49BE4253.20808@gmail.com> <1237240051.22402.529.camel@localhost> Message-ID: <1237245465.22402.540.camel@localhost> On Mon, 2009-03-16 at 16:04 -0700, Conal Elliott wrote: > On Mon, Mar 16, 2009 at 2:47 PM, Duncan Coutts > wrote: > On Mon, 2009-03-16 at 12:13 +0000, Simon Marlow wrote: > > Perhaps I'm missing something, but if applicative-numbers is > an exposed > > package, shouldn't we be adding its include-dirs when > invoking CPP? > > > Yes, if we know we're using it. If we specify -package blah on > the > command line then we do know we're using it and everything > works > (because ghc uses the include-dirs when it calls cpp). If we > don't > specify -package then ghc does not know we need the package > until after > import chasing is done. Import chasing requires that we run > cpp on > the .hs file first and that brings us full circle. > > Duncan > > Unless you drop the cpp-first requirement and have import-chasing look > into #include'd files, as I described earlier. - Conal Yes, that's what I said earlier about re-implementing cpp, possibly via cpphs. That would let you chase #includes and assuming you know which packages provide which include files then we could work out which packages are needed for cpp-ing. Or you could play it fast and loose and assume that you can usually ignore # cpp lines and still work out what the Haskell imports are most of the time. That's not correct but is probably easier and would probably work most of the time. Neither approach is easy or very nice. Duncan From marlowsd at gmail.com Tue Mar 17 04:53:33 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 17 04:41:36 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: <1237240051.22402.529.camel@localhost> References: <1237120068.22402.515.camel@localhost> <49BE4253.20808@gmail.com> <1237240051.22402.529.camel@localhost> Message-ID: <49BF650D.3000409@gmail.com> Duncan Coutts wrote: > On Mon, 2009-03-16 at 12:13 +0000, Simon Marlow wrote: > >>> This sounds like a chicken and egg problem. To know which package >>> include directories to use GHCi needs to know which packages your module >>> uses. However to work out which packages it needs it has to load the >>> module which means pre-processing it! >>> >>> With cabal we get round this problem because Cabal calls ghc with >>> -package this -package that etc and so when ghc cpp's the module it does >>> know which package include directories to look in. >> Perhaps I'm missing something, but if applicative-numbers is an exposed >> package, shouldn't we be adding its include-dirs when invoking CPP? > > Yes, if we know we're using it. If we specify -package blah on the > command line then we do know we're using it and everything works > (because ghc uses the include-dirs when it calls cpp). If we don't > specify -package then ghc does not know we need the package until after > import chasing is done. Import chasing requires that we run cpp on > the .hs file first and that brings us full circle. I don't see a reason why we shouldn't pass *all* the include paths for the exposed packages to CPP. Indeed that's what I thought we did, but I've just checked and I see we don't. Wouldn't that fix Conal's problem? Cheers, Simon From duncan.coutts at worc.ox.ac.uk Tue Mar 17 05:57:28 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Mar 17 05:45:26 2009 Subject: ghci finding include files exported from other packages? In-Reply-To: <49BF650D.3000409@gmail.com> References: <1237120068.22402.515.camel@localhost> <49BE4253.20808@gmail.com> <1237240051.22402.529.camel@localhost> <49BF650D.3000409@gmail.com> Message-ID: <1237283848.22402.562.camel@localhost> On Tue, 2009-03-17 at 08:53 +0000, Simon Marlow wrote: > Duncan Coutts wrote: > > On Mon, 2009-03-16 at 12:13 +0000, Simon Marlow wrote: > > > > Yes, if we know we're using it. If we specify -package blah on the > > command line then we do know we're using it and everything works > > (because ghc uses the include-dirs when it calls cpp). If we don't > > specify -package then ghc does not know we need the package until after > > import chasing is done. Import chasing requires that we run cpp on > > the .hs file first and that brings us full circle. > > I don't see a reason why we shouldn't pass *all* the include paths for the > exposed packages to CPP. Indeed that's what I thought we did, but I've > just checked and I see we don't. Wouldn't that fix Conal's problem? Yes it probably would. On my system that'd only be between 25-50 include directories, which I guess is not too bad. Lets hope not too many packages decide they need a "config.h" file. So, presumably by passing all include dirs for all exposed packages that takes into account -package flags, so when Cabal does -hide-all-packages then it gets its desired behaviour. Duncan From Christian.Maeder at dfki.de Tue Mar 17 06:09:21 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Mar 17 05:57:19 2009 Subject: Under Solaris: GHC 6.10.2 Release Candidate 1 In-Reply-To: <49BE6979.9030304@dfki.de> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> Message-ID: <49BF76D1.4060508@dfki.de> GHC 6.10.2 will have a problem with cabal-install-0.6.2! When I tried to install cabal-install-0.6.2 for ghc-6.10.1.20090314 I needed to change #!/bin/sh to #!/bin/bash in bootstrap.sh to avoid the following errors: -bash-3.00$ ./bootstrap.sh Checking installed packages for ghc-6.10.1.20090314... ./bootstrap.sh: !: not found parsec is already installed and the version is ok. ./bootstrap.sh: !: not found network is already installed and the version is ok. ./bootstrap.sh: !: not found Cabal is already installed and the version is ok. ./bootstrap.sh: !: not found HTTP is already installed and the version is ok. ./bootstrap.sh: !: not found zlib is already installed and the version is ok. ./bootstrap.sh: !: not found ./bootstrap.sh: !: not found ./bootstrap.sh: !: not found Under Solaris sh is not bash! Next, ghc-6.10.1.20090314 comes with package unix-2.4.0.0, but cabal-install.cabal requests: unix >= 2.0 && < 2.4 Changing to "<= 2.4" was not sufficient, so I changed it to "<= 2.5". This will affect any OS! Testsuite results are bad for ghc-6.10.1.20090314, see http://hackage.haskell.org/trac/ghc/ticket/3106 Cheers Christian Christian Maeder wrote: > Ian Lynagh wrote: >> We are pleased to announce the first release candidate for GHC 6.10.2: >> >> http://www.haskell.org/ghc/dist/6.10.2-rc1/ > > Under Solaris grep does not understand "-q" in configure: > > checkMake380() { > if $1 --version 2>&1 | head -1 | grep -q 'GNU Make 3\.80' > > it fails with: > > grep: illegal option -- q > Usage: grep -hblcnsviw pattern file . . . > grep: illegal option -- q > Usage: grep -hblcnsviw pattern file . . . > > C. From p.k.f.holzenspies at utwente.nl Tue Mar 17 06:40:57 2009 From: p.k.f.holzenspies at utwente.nl (Philip K.F. =?ISO-8859-1?Q?H=F6lzenspies?=) Date: Tue Mar 17 06:27:33 2009 Subject: Developer Wiki & Buildbots Message-ID: <1237286457.32155.3.camel@ewi1043> Dear all, It seems that the front page of the developer wiki is rather out-of-date. Considering that 6.10.2 is now at rc1-stage, I was rather hoping to find some updated notes on release plans for 6.10.2 and what will be in 6.12, but those notices are still at 6.8.3 and 6.10, resp. On another matter: I've been trying to contact Ian on rejoining the buildbot network, but haven't heard from him in response to any of messages. Ian, I figured I may have - somehow - ended up in your spam-box, so I thought it a good idea to go through the mailing list. Could you maybe check your spam-box for my e-mails? Regards, Philip From karel.gardas at centrum.cz Tue Mar 17 07:51:23 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue Mar 17 07:39:04 2009 Subject: Under Solaris: GHC 6.10.2 Release Candidate 1 In-Reply-To: <49BF76D1.4060508@dfki.de> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> <49BF76D1.4060508@dfki.de> Message-ID: <49BF8EBB.30607@centrum.cz> Christian Maeder wrote: > Testsuite results are bad for ghc-6.10.1.20090314, see > http://hackage.haskell.org/trac/ghc/ticket/3106 Patch for the cygpath not found issue is attached to the ticket. Please (Windows/Cygwin/Mingw users especially) test it. Thanks, Karel From marlowsd at gmail.com Tue Mar 17 08:17:36 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 17 08:05:39 2009 Subject: Developer Wiki & Buildbots In-Reply-To: <1237286457.32155.3.camel@ewi1043> References: <1237286457.32155.3.camel@ewi1043> Message-ID: <49BF94E0.4000906@gmail.com> Philip K.F. H?lzenspies wrote: > It seems that the front page of the developer wiki is rather > out-of-date. Considering that 6.10.2 is now at rc1-stage, I was rather > hoping to find some updated notes on release plans for 6.10.2 and what > will be in 6.12, but those notices are still at 6.8.3 and 6.10, resp. Good point, I've just updated it. Cheers, Simon From marlowsd at gmail.com Tue Mar 17 08:18:02 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 17 08:06:04 2009 Subject: testing 6.10.2-candidate In-Reply-To: <20090316174325.GA16997@scico.botik.ru> References: <20090316174325.GA16997@scico.botik.ru> Message-ID: <49BF94FA.8010102@gmail.com> Serge D. Mechveliani wrote: > I have tested ghc-6.10.1.20090314 on Debian Linux, i386-unknown, > on > making from source by ghc-6.10.1, making itself from source, DoCon. > > It looks all right. Thanks Serge! Simon From stryder100 at gmail.com Tue Mar 17 09:02:37 2009 From: stryder100 at gmail.com (Ralph Crawford) Date: Tue Mar 17 08:50:35 2009 Subject: Solaris 8 and libm.so.2 Message-ID: Hi everyone. I'm trying to build GHC 6.8.3 on a Solaris 8 machine. I'd love to upgrade Solaris to 10, which I believe would solve the problem I'm having by making /usr/lib/libm.so.2 available, but that's not an option at this time. Here's the output of uname -a on the system. SunOS bwddev1 5.8 Generic_117350-53 sun4u sparc SUNW,Ultra-80 The GCC I'm using is gcc Target: sparc-sun-solaris2.8 Configured with: /usr/local/src/gnu/gcc-4.0.1/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --prefix=/usr/local/gcc4 Thread model: posix gcc version 4.0.1 The GHC binary I'm bootstrapping with is 6.4.1. It works fine for compiling complex haskell programs and packages. I've already worked through a couple of problems to get to where I'm at now. What I had to do was... changed #define SIZET_FMT "d" to #define SIZET_FMT "d" in includes/mkDerivedConstances.c. change #include to #include in includes/HsFFI.h added mk/build.mk containing SRC_HC_OPTS=-opta-mcpu=v9 My latest attempt at a build involved the following, where BOS_ROOT points at the root of my build tree, and $BOS_ROOT/gcc4 is where my gcc lives, and $BOS_ROOT/ghc is where the ghc binary lives. This is only the latest attempt. The libm.so.2 symbolic link and the LDFLAGS and LD_LIBRARY_PATH values were added on the most recent attempt. ln -s /usr/lib/libm.so.1 $BOS_ROOT/lib/libm.so.2 PATH=$BOS_ROOT/gcc4/bin:$BOS_ROOT/ghc/bin:$BOS_ROOT/bin:/usr/bin:/bin LD_LIBRARY_PATH=$BOS_ROOT/gcc4/lib:$BOS_ROOT/ghc/lib:$BOS_ROOT/lib:/usr/lib LDFLAGS=-static -L$BOS_ROOT/lib CFLAGS= export PATH LD_LIBRARY_PATH LDFLAGS CFLAGS fp_prog_ld_raw=/usr/ccs/bin/ld ./configure \ --prefix=$BOS_ROOT \ --with-ghc=$BOS_ROOT/ghc/bin/ghc \ --with-as=/usr/ccs/bin/as \ --with-ld=/usr/ccs/bin/ld \ --with-gcc=$BOS_ROOT/gcc4/bin/gcc \ --with-gmp-includes=$BOS_ROOT/include \ --with-gmp-libraries=$BOS_ROOT/lib \ --with-readline-includes=$BOS_ROOT/include \ --with-readline-libraries=$BOS_ROOT/lib Once I made these changes, the build goes on for a number of hours then dies with what's listed below. I understand that this is because the build is looking for libm.so.2, while the lib on Solaris 8 is /usr/lib/libm.so.1. No matter what I do - including the kludge above attempting to create a libm.so.2 symbolic link, I can't get rid of the errors. Any help at all would be very much appreciated. Please. Here's the error listing. make[3]: Entering directory `/winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/compiler' ../compiler/stage1/ghc-inplace -no-user-package-conf -opta-mcpu=v9 -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp -c main/Main.hs -o stage2/main/Main.o -ohi stage2/main/Main.hi <> ../compiler/stage1/ghc-inplace -no-user-package-conf -o stage2/ghc-6.8.3 -opta-mcpu=v9 -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp stage2/main/Main.o Undefined first referenced symbol in file cosf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__169.o) expf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__173.o) logf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__172.o) powf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__161.o) sinf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__170.o) tanf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__168.o) acosf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__166.o) asinf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__167.o) atanf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__165.o) coshf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__163.o) dlsym /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/rts/libHSrts_thr.a(Linker.thr_o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) sinhf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__164.o) tanhf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__162.o) sqrtf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__171.o) dlopen /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/rts/libHSrts_thr.a(Linker.thr_o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) dlerror /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/rts/libHSrts_thr.a(Linker.thr_o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) ld: fatal: Symbol referencing errors. No output written to stage2/ghc-6.8.3 collect2: ld returned 1 exit status <> make[3]: *** [stage2/ghc-6.8.3] Error 1 make[3]: Leaving directory `/winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/compiler' make[2]: *** [stage2/ghc-6.8.3] Error 2 make[2]: Leaving directory `/winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3' make: *** [bootstrap2] Error 2 -- --------------------------------------------------------------- My web host for www.ralphcrawford.org is... http://www.1and1.com/?k_id=6466911 They're good - I recommend them. I'm switching my email from stryder22204@yahoo.com to stryder100@gmail.com. Don't worry though I'll still get stuff from the stryder22204 address for about 6 months. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090317/07fdbcd7/attachment-0001.htm From Christian.Maeder at dfki.de Tue Mar 17 10:36:37 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Mar 17 10:24:32 2009 Subject: Solaris 8 and libm.so.2 In-Reply-To: References: Message-ID: <49BFB575.6080001@dfki.de> Ralph Crawford wrote: > ln -s /usr/lib/libm.so.1 $BOS_ROOT/lib/libm.so.2 You need an actual libm.so.2 library that contains the missing symbols. To this library you set a link libm.so in a directory that is in the front of your LD_LIBRARY_PATH, so that libm.so.2 instead of libm.so.1 is found via libm.so. HTH Christian From allbery at ece.cmu.edu Tue Mar 17 11:17:55 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Mar 17 11:06:04 2009 Subject: Solaris 8 and libm.so.2 In-Reply-To: <49BFB575.6080001@dfki.de> References: <49BFB575.6080001@dfki.de> Message-ID: <449EF55D-DF5E-4629-8028-80003D1822AB@ece.cmu.edu> On 2009 Mar 17, at 10:36, Christian Maeder wrote: > Ralph Crawford wrote: >> ln -s /usr/lib/libm.so.1 $BOS_ROOT/lib/libm.so.2 > > You need an actual libm.so.2 library that contains the missing > symbols. > To this library you set a link libm.so in a directory that is in the > front of your LD_LIBRARY_PATH, so that libm.so.2 instead of libm.so. > 1 is > found via libm.so. It's a bit more complex than that: if you have the appropriate service contract you can request the C9X patch cluster, otherwise you can't get libm.so.2 at all, as far as I can determine. I came up with an ugly hack to work around it, but would prefer to find a better solution. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090317/092e11e7/PGP.bin From colin at colina.demon.co.uk Tue Mar 17 15:20:06 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Mar 17 15:08:03 2009 Subject: Bootstrapping the compiler Message-ID: I have just downloaded a darcs snapshot, pulled patches and followed the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart When I got to do make it didn't work. The tail of the output looks like this: [55 of 55] Compiling Main ( cabal-bin.hs, /home/colin/ghc/libraries/bootstrapping/Main.o ) Linking cabal-bin ... echo "[]" > bootstrapping.conf.tmp cd extensible-exceptions && /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 clean --distpref=dist-bootstrapping unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: [bootstrapping.conf] Error 1 (ignored) cd extensible-exceptions && /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 configure --distpref=dist-bootstrapping --with-compiler=ghc --make -fno-warn-unrecognised-pragmas --with-hc-pkg=/usr/local/bin/ghc-pkg --package-db=/home/colin/ghc/libraries/bootstrapping.conf.tmp unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/home/colin/ghc/libraries' make: *** [stage1] Error 2 I then tried the following: [colin@susannah ghc]$ ls libraries/bootstrapping.conf ls: cannot access libraries/bootstrapping.conf: No such file or directory [colin@susannah ghc]$ ls libraries/bootstrapping.conf.tmp libraries/bootstrapping.conf.tmp It looks to me like all I have to do is to rename libraries/bootstrapping.conf.tmp to libraries/bootstrapping.conf but I don't see why this is happening. -- Colin Adams Preston Lancashire From duncan.coutts at worc.ox.ac.uk Tue Mar 17 20:28:50 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Mar 17 20:16:48 2009 Subject: Under Solaris: GHC 6.10.2 Release Candidate 1 In-Reply-To: <49BF76D1.4060508@dfki.de> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> <49BF76D1.4060508@dfki.de> Message-ID: <1237336130.22402.577.camel@localhost> On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote: > GHC 6.10.2 will have a problem with cabal-install-0.6.2! > > When I tried to install cabal-install-0.6.2 for ghc-6.10.1.20090314 > I needed to change #!/bin/sh to #!/bin/bash in bootstrap.sh to avoid the > following errors: > > -bash-3.00$ ./bootstrap.sh > Checking installed packages for ghc-6.10.1.20090314... > ./bootstrap.sh: !: not found > Under Solaris sh is not bash! Indeed. According to the OpenGroup that syntax should be fine: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_02 It works for me under Solaris 10. Perhaps Solaris 9 or older do not have a standard compliant /bin/sh program. What do you suggest we use instead as a workaround? > Next, ghc-6.10.1.20090314 comes with package unix-2.4.0.0, but > cabal-install.cabal requests: > > unix >= 2.0 && < 2.4 > > Changing to "<= 2.4" was not sufficient, so I changed it to "<= 2.5". > This will affect any OS! Hmm, it's a bit suspicious that the major version number is changing in a minor ghc release. Do we know what the API breakage is? This could affect any program. Duncan From allbery at ece.cmu.edu Tue Mar 17 21:12:19 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Mar 17 21:00:35 2009 Subject: Under Solaris: GHC 6.10.2 Release Candidate 1 In-Reply-To: <1237336130.22402.577.camel@localhost> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> <49BF76D1.4060508@dfki.de> <1237336130.22402.577.camel@localhost> Message-ID: <9F8CB8D7-D28B-4F46-95ED-3DDA921515C3@ece.cmu.edu> On 2009 Mar 17, at 20:28, Duncan Coutts wrote: > On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote: >> Under Solaris sh is not bash! > > Indeed. > > According to the OpenGroup that syntax should be fine: > http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_02 > > It works for me under Solaris 10. Perhaps Solaris 9 or older do not > have > a standard compliant /bin/sh program. What do you suggest we use > instead > as a workaround? For backward compatibility reasons sh in Solaris 9 and earlier is not POSIX compliant. Use /usr/xpg4/bin/sh or /bin/bash instead. (Unfortunately you can't cheat and define a shell function, although you could create a program called "!": #! /bin/sh if ${1+"$@"}; then exit 1 else exit 0 fi .) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090317/90b84acb/PGP.bin From simonpj at microsoft.com Wed Mar 18 04:45:49 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Mar 18 04:33:45 2009 Subject: [Haskell] Re: indirectly recursive dictionaries In-Reply-To: <20090318032653.50C67AF97@Adric.metnet.fnmoc.navy.mil> References: <20090318032653.50C67AF97@Adric.metnet.fnmoc.navy.mil> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C334CBB6055C@EA-EXMSG-C334.europe.corp.microsoft.com> [Redirecting to GHC users.] | Tom Schrijvers wrote: | > The cyclic dictionaries approach is a bit fragile. The problem appears to | > be here that GHC alternates exhaustive phases of constraint reduction and | > functional dependency improvement. The problem is that in your example you | > need both for detecting a cycle. The whole thing relies on "spotting a loop", and that's inherently a bit fragile. I don't know of any formal work on the subject, although I bet there is some. GHC's current algorithm does not run functional dependencies sufficiently aggressively, because it treats fundeps a different kind of thing to class constraints. Our new solver, long promised but still in the works, fully integrates type classes with type equalities (fundeps, type functions etc), and so should do a better job here. Roughly speaking, the idea is to combine our ICFP'08 paper [1] with a type-class solver. Since writing the ICFP'08 paper we have found some very useful simplifications; and we also have a new plan for the solving strategy "OutsideIn" [2]. That said, solving recursive problems is not our primary focus right now -- getting it working is -- so I can't promise that it'll do a better job, but I think it will. | It seems we can convince GHC to do constraint reduction and | improvement in the order we desire. The key is to use the | continuation-passing style -- which forces things to happen in the | right order, both at the run-time and at the compile time. Oleg you are a master at persuading GHC's somewhat ad-hoc implementation to dance to your tune. But it'd be better just to make the implementation more complete in the solutions it finds. That's what we are working on now. Simon [1] http://research.microsoft.com/~simonpj/papers/assoc-types/index.htm [2] http://research.microsoft.com/~simonpj/papers/gadt From Christian.Maeder at dfki.de Wed Mar 18 04:56:07 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Mar 18 04:44:01 2009 Subject: Under Solaris: GHC 6.10.2 Release Candidate 1 In-Reply-To: <1237336130.22402.577.camel@localhost> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> <49BF76D1.4060508@dfki.de> <1237336130.22402.577.camel@localhost> Message-ID: <49C0B727.7040201@dfki.de> Duncan Coutts wrote: > On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote: >> ./bootstrap.sh: !: not found > >> Under Solaris sh is not bash! > > Indeed. > > According to the OpenGroup that syntax should be fine: > http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_02 > > It works for me under Solaris 10. Perhaps Solaris 9 or older do not have > a standard compliant /bin/sh program. What do you suggest we use instead > as a workaround? The Isabelle people use "#!/usr/bin/env bash" as first line. Btw I had this problem under Solaris 10 (but I don't know how it was installed). Cheers Christian From duncan.coutts at worc.ox.ac.uk Wed Mar 18 05:17:17 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 18 05:05:11 2009 Subject: Under Solaris: GHC 6.10.2 Release Candidate 1 In-Reply-To: <9F8CB8D7-D28B-4F46-95ED-3DDA921515C3@ece.cmu.edu> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> <49BF76D1.4060508@dfki.de> <1237336130.22402.577.camel@localhost> <9F8CB8D7-D28B-4F46-95ED-3DDA921515C3@ece.cmu.edu> Message-ID: <1237367837.7437.9.camel@localhost> On Tue, 2009-03-17 at 21:12 -0400, Brandon S. Allbery KF8NH wrote: > On 2009 Mar 17, at 20:28, Duncan Coutts wrote: > > It works for me under Solaris 10. Perhaps Solaris 9 or older do not > > have a standard compliant /bin/sh program. What do you suggest we use > > instead as a workaround? > For backward compatibility reasons sh in Solaris 9 and earlier is not > POSIX compliant. Use /usr/xpg4/bin/sh or /bin/bash instead. > (Unfortunately you can't cheat and define a shell function, although > you could create a program called "!": > if ${1+"$@"}; then > exit 1 > else > exit 0 > fi Actually this is what the script used 'til someone pointed out to me that sh has the ! syntax :-). I'll switch it back to using this style with a note to say why. Duncan - ! grep " ${PKG}-${VER_MATCH}" ghc-pkg.list > /dev/null 2>&1 + if grep " ${PKG}-${VER_MATCH}" ghc-pkg.list > /dev/null 2>&1 + then + return 1; + else + return 0; + fi + #Note: we cannot use "! grep" as Solaris 9 /bin/sh doesn't like it. From gwright at comcast.net Wed Mar 18 06:51:31 2009 From: gwright at comcast.net (Gregory Wright) Date: Wed Mar 18 06:40:05 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 Message-ID: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as a bootstrap compiler. The build was done using the MacPorts infrastructure. Summary test results: OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 2334 total tests, which gave rise to 12487 test cases, of which 0 caused framework failures 2460 were skipped 9709 expected passes 258 expected failures 0 unexpected passes 60 unexpected failures Unexpected failures: 2469(ghci) apirecomp001(normal) bits (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) conc049(hpc) conc068(normal) derefnull(profc,profthreaded) divbyzero(profc,profthreaded) genUpTo (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) num012 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) signals002(ghci) signals004(ghci,threaded1,threaded2,profthreaded) I haven't looked at the errors in detail, but generally the release candidate seems OK. BTW, a test target will be added to MacPorts's portfile for the 6.10.2 release, which will let you run the test suite by typing > sudo port test ghc and if you then install the tested build, a record of the test will be saved in $PREFIX/share/ghc-/. Best Wishes, Greg From naur at post11.tele.dk Wed Mar 18 07:35:01 2009 From: naur at post11.tele.dk (Thorkil Naur) Date: Wed Mar 18 07:25:32 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090315155142.GA18000@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> Message-ID: <200903181235.01963.naur@post11.tele.dk> Hello, On Sunday 15 March 2009 16:51, Ian Lynagh wrote: > > We are pleased to announce the first release candidate for GHC 6.10.2: > ... > Please test as much as possible; bugs are much cheaper if we find them > before the release! > ... I have tried the Intel Mac installer and the source package on both FreeBSD and PPC Mac OS X. Some comments follow, first on GHC-6.10.1.20090314-i386.pkg: 1. An important property of such installers is that you are told, right from the start, that all the information you are presented with during the installation process can be accessed at any time, after completion of the installation, and you are told how. In case of GHC, something like a reference to a suitable spot, given as part of the output from ghc --help. I don't see any trace of such a facility on the introduction screen. (I know that other installers don't do this either, which is part of the reason why I try to avoid them.) 2. The introduction screen says "This package must be installed on the system volume" which seems to imply that there is some kind of choice involved at a later stage. But I don't recall having to perform any choice that related to this. So perhaps this should be "This package will be installed on the system volume" instead. 3. I can copy and paste the text of the introduction screen, excellent. I cannot copy and paste the header. 4. On the License screen, GMP is denoted "GNU MP Bignum Library" in two places. I suggest using "GNU Multiple Precision Arithmetic Library" (from http://gmplib.org/) instead. 5. On the License screen, replace "licence" by "license", twice. 6. The License screen explains "that by default the GMP will be statically linked into any binary produced by GHC. Software with a non-GPL compatible licence [sic] will have to ensure that the conditions of the LGPL are met; for example, by forcing GMP to link dynamically instead." Some details or a reference to an explanation of how to do this would be nice. Also, shouldn't "non-GPL compatible" be plain "non-GPL"? 7. I may very well be wrong, but as far as I have been able to tell, the ghc executable itself that is distributed (/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc) contains GMP, statically linked. For example: > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES /usr/bin/ghc --version > dyld: loaded: /bin/sh > dyld: loaded: /usr/lib/libncurses.5.4.dylib > dyld: loaded: /usr/lib/libiconv.2.dylib > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /usr/lib/libgcc_s.1.dylib > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > dyld: loaded: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc > dyld: loaded: /usr/lib/libedit.2.dylib > dyld: loaded: /usr/lib/libncurses.5.4.dylib > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /usr/lib/libgcc_s.1.dylib > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > The Glorious Glasgow Haskell Compilation System, version 6.10.1.20090314 > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where I fail to observe anything that seems to relate to GMP. This is in contrast to the corresponding information for an earlier GHC installation > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ DYLD_PRINT_LIBRARIES=YES ghc --version > dyld: loaded: /bin/sh > dyld: loaded: /usr/lib/libncurses.5.4.dylib > dyld: loaded: /usr/lib/libiconv.2.dylib > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /usr/lib/libgcc_s.1.dylib > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > dyld: loaded: /Users/thorkilnaur/tn/install/ghc-6.8.3/lib/ghc-6.8.3/ghc-6.8.3 > dyld: loaded: /opt/local/lib/libreadline.5.2.dylib > dyld: loaded: /opt/local/lib/libncurses.5.dylib > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /opt/local/lib/libgmp.3.dylib > dyld: loaded: /usr/lib/libgcc_s.1.dylib > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > The Glorious Glasgow Haskell Compilation System, version 6.8.3 > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 thorkilnaur$ where one observes the presence of "dyld: loaded: /opt/local/lib/libgmp.3.dylib" that loads the separately installed dynamic GMP library. I am no expert in these matters, but this seems to activate requirement d) 0) under section "4. Combined Works" of the LGPL "GNU LESSER GENERAL PUBLIC LICENSE Version 3, 29 June 2007" (http://www.fsf.org/licensing/licenses/lgpl.html) which talks about providing material and giving instructions about how to re-link with a new version of the library and all that. If this material and the instructions are present in the installation package, I have failed to notice it. Alternatively, if the ghc executable links to GMP dynamically, requirement d) 1) of the LGPL comes into effect and that talks about a "mechanism ...that ... uses at run time a copy of the Library already present on the user's computer system". In the latter case, I would expect a mentioning of this requirement of a separate GMP installation and I have not seen such a requirement mentioned. 8. I can copy and paste the text of the License screen (without the header), excellent. (I can also Print and Save, I haven't tried that.) 9. I cannot copy and paste the text or the header of the Installation Type screen, the one that says "This will take 448 MB of space on your computer. Click Install to perform a standard installation of this software for all users of this computer." 10. On the Summary screen, I am told to find additional documentation at "/usr/share/doc/ghc/index.html". Should that, perhaps, be "file:///usr/share/doc/ghc/index.html" or something else, that more directly indicates how to access this documentation? And also mention the use of a browser? 11. And there is an uninstaller, excellent. Not least because reading that allows me to figure out where (the author of the uninstaller believes) things are installed. I didn't check before installing, but certainly, running the uninstaller increased the available space on the disk by about 500 MBytes, the expected amount. 12. What happens if I have a GHC installed already? To check this, I tried running the installer twice, without uninstalling in between. I didn't notice any difference between the first and second install. So I guess that the first installation was simply being overwritten. I realise that the /Library/Framework conventions allow multiple versions of the same thing to be installed. But the way the GHC package is supposed to be accessed is via symbolic links in /usr/bin (and elsewhere?) and these links are surely being overwritten. If there is a mechanism for changing between versions, I haven't noticed it. 13. Looking inside /usr/share/doc/ghc, I find LICENSE, but this is not the same as the text of the License screen. 14. I also find /usr/share/doc/ghc/docbook-cheat-sheet which could be left out without doing much harm, as far as I can tell. 15. I didn't run the testsuite for the Intel Mac installer. Then we are getting to the source distribution (ghc-6.10.1.20090314-src-extralibs.tar.bz2, ghc-6.10.1.20090314-src.tar.bz2 and also the testsuite-6.10.1.20090314.tar.gz). I tried that on a FreeBSD and also a PPC Mac OS X. First comes > $ uname -a > FreeBSD tn12.thorkilnaur.dk 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.10.1 16. The build, using ./configure + make, went fine. Running the tests ran into the issue described as http://hackage.haskell.org/trac/ghc/ticket/3106. Using the proposed fix provided by kgardas (my own proposed fix wasn't ready until later), the testsuite (make stage=2) ended with this summary: > OVERALL SUMMARY for test run started at Tue Mar 17 14:03:34 CET 2009 > 2334 total tests, which gave rise to > 12487 test cases, of which > 0 caused framework failures > 2460 were skipped > > 9680 expected passes > 262 expected failures > 15 unexpected passes > 70 unexpected failures > > Unexpected passes: > galois_raytrace(hpc,optasm,profasm,threaded2,profthreaded) > getEnvironment01 (normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > Unexpected failures: > apirecomp001(normal) > barton-mangler-bug(hpc,profc) > bits(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > break017(ghci) > cabal01(normal) > concprog001(ghci) > derefnull(profc,profthreaded) > divbyzero(profc,profthreaded) > genUpTo(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > hpc_raytrace(profc) > joao-circular(profc) > length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) > num009 (normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > num012 (normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > process007 (normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > seward-space-leak(ghci) Details may be found at: thorkilnaur.dk/~tn/test/GHC/release/GHC-6.10.2-rc1/ghc-6.10.1.20090314-freebsd.tar.gz Second comes > $ uname -a > Darwin thorkil-naurs-mac-mini.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:39:01 PST 2008; root:xnu-1228.9.59~1/RELEASE_PPC Power Macintosh > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.6.1 17. Again, building with ./configure + make went fine. Test summary (make stage=2): > OVERALL SUMMARY for test run started at Tue Mar 17 08:48:51 CET 2009 > 2334 total tests, which gave rise to > 12487 test cases, of which > 0 caused framework failures > 2453 were skipped > > 9726 expected passes > 254 expected failures > 0 unexpected passes > 54 unexpected failures > > Unexpected failures: > 2469(ghci) > apirecomp001(normal) > barton-mangler-bug(profc) > bits(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > break017(ghci) > derefnull(profc,profthreaded) > divbyzero(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > ffi009(ghci) > galois_raytrace(optc,profc) > genUpTo(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > hpc_raytrace(profc) > joao-circular(profc) > length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) > seward-space-leak(ghci) > signals002(ghci) > signals004(ghci,threaded1,threaded2,profthreaded) Details at: thorkilnaur.dk/~tn/test/GHC/release/GHC-6.10.2-rc1/ghc-6.10.1.20090314-ppc-macosx.tar.gz Best regards Thorkil From colin at colina.demon.co.uk Wed Mar 18 07:41:32 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Mar 18 07:29:28 2009 Subject: Bootstrapping the compiler In-Reply-To: (Colin Paul Adams's message of "Tue\, 17 Mar 2009 19\:20\:06 +0000") References: Message-ID: I tried again with the same result. Is this a known problem, or do I have investigate myself? >>>>> "Colin" == Colin Paul Adams writes: Colin> I have just downloaded a darcs snapshot, pulled patches and Colin> followed the instructions at Colin> http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart Colin> When I got to do Colin> make Colin> it didn't work. The tail of the output looks like this: Colin> [55 of 55] Compiling Main ( cabal-bin.hs, Colin> /home/colin/ghc/libraries/bootstrapping/Main.o ) Linking Colin> cabal-bin ... echo "[]" > bootstrapping.conf.tmp cd Colin> extensible-exceptions && Colin> /home/colin/ghc/libraries/cabal-bin ghc --make Colin> -fno-warn-unrecognised-pragmas Colin> /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 clean Colin> --distpref=dist-bootstrapping unrecognised command: Colin> /home/colin/ghc/libraries/bootstrapping.conf (try --help) Colin> make[1]: [bootstrapping.conf] Error 1 (ignored) cd Colin> extensible-exceptions && Colin> /home/colin/ghc/libraries/cabal-bin ghc --make Colin> -fno-warn-unrecognised-pragmas Colin> /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 Colin> configure --distpref=dist-bootstrapping --with-compiler=ghc Colin> --make -fno-warn-unrecognised-pragmas Colin> --with-hc-pkg=/usr/local/bin/ghc-pkg Colin> --package-db=/home/colin/ghc/libraries/bootstrapping.conf.tmp Colin> unrecognised command: Colin> /home/colin/ghc/libraries/bootstrapping.conf (try --help) Colin> make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving Colin> directory `/home/colin/ghc/libraries' make: *** [stage1] Colin> Error 2 Colin> I then tried the following: Colin> [colin@susannah ghc]$ ls libraries/bootstrapping.conf ls: Colin> cannot access libraries/bootstrapping.conf: No such file or Colin> directory [colin@susannah ghc]$ ls Colin> libraries/bootstrapping.conf.tmp Colin> libraries/bootstrapping.conf.tmp Colin> It looks to me like all I have to do is to rename Colin> libraries/bootstrapping.conf.tmp Colin> to Colin> libraries/bootstrapping.conf Colin> but I don't see why this is happening. -- Colin Adams Preston Lancashire From colin at colina.demon.co.uk Wed Mar 18 07:51:58 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Mar 18 07:39:57 2009 Subject: Bootstrapping the compiler In-Reply-To: (Colin Paul Adams's message of "Wed\, 18 Mar 2009 11\:41\:32 +0000") References: Message-ID: >>>>> "Colin" == Colin Paul Adams writes: Colin> I tried again with the same result. Is this a known Colin> problem, or do I have investigate myself? >>>>> "Colin" == Colin Paul Adams writes: Colin> I have just downloaded a darcs snapshot, pulled patches and P.S. This was the January 2009 snapshot of HEAD (the 118 MB version). -- Colin Adams Preston Lancashire From marlowsd at gmail.com Wed Mar 18 08:20:06 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Mar 18 08:08:06 2009 Subject: Bootstrapping the compiler In-Reply-To: References: Message-ID: <49C0E6F6.3060505@gmail.com> Colin Paul Adams wrote: > I have just downloaded a darcs snapshot, pulled patches and followed > the instructions at > http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart > > When I got to do > > make > > it didn't work. The tail of the output looks like this: > > [55 of 55] Compiling Main ( cabal-bin.hs, /home/colin/ghc/libraries/bootstrapping/Main.o ) > Linking cabal-bin ... > echo "[]" > bootstrapping.conf.tmp > cd extensible-exceptions && /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 clean --distpref=dist-bootstrapping > unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) > make[1]: [bootstrapping.conf] Error 1 (ignored) > cd extensible-exceptions && /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 configure --distpref=dist-bootstrapping --with-compiler=ghc --make -fno-warn-unrecognised-pragmas --with-hc-pkg=/usr/local/bin/ghc-pkg --package-db=/home/colin/ghc/libraries/bootstrapping.conf.tmp > unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) > make[1]: *** [bootstrapping.conf] Error 1 Your problem appears to be that you have set $(GHC) to ghc --make -fno-warn-unrecognised-pragmas $(GHC) should be set to the path to GHC, nothing else. Cheers, Simon From marlowsd at gmail.com Wed Mar 18 08:26:50 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Mar 18 08:14:48 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 In-Reply-To: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> References: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> Message-ID: <49C0E88A.3040202@gmail.com> Gregory Wright wrote: > > I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as > a bootstrap compiler. The build was done using the MacPorts > infrastructure. > > Summary test results: > > OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 > 2334 total tests, which gave rise to > 12487 test cases, of which > 0 caused framework failures > 2460 were skipped > > 9709 expected passes > 258 expected failures > 0 unexpected passes > 60 unexpected failures > > Unexpected failures: > 2469(ghci) > apirecomp001(normal) > > bits(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > conc049(hpc) > conc068(normal) > derefnull(profc,profthreaded) > divbyzero(profc,profthreaded) > > genUpTo(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) > > num009(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > > num012(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > signals002(ghci) > signals004(ghci,threaded1,threaded2,profthreaded) Thanks. We really need people to look at these failing tests and either fix them or submit tickets as necessary. Volunteers? For num009 and num012, I've turned these on as part of validate which will force the problems to the surface. Cheers, Simon From colin at colina.demon.co.uk Wed Mar 18 08:32:02 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Mar 18 08:19:58 2009 Subject: Bootstrapping the compiler In-Reply-To: <49C0E6F6.3060505@gmail.com> (Simon Marlow's message of "Wed\, 18 Mar 2009 12\:20\:06 +0000") References: <49C0E6F6.3060505@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> Your problem appears to be that you have set $(GHC) to Simon> ghc --make -fno-warn-unrecognised-pragmas Simon> $(GHC) should be set to the path to GHC, nothing else. You're right. I was using that prior to cabalizing my other project. I'll scrap it now. Thanks. -- Colin Adams Preston Lancashire From nominolo at googlemail.com Wed Mar 18 10:03:51 2009 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Mar 18 09:51:52 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 In-Reply-To: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> References: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> Message-ID: <2B2A5BDC-B4A7-4E2D-A42D-B190A0A9FDA2@googlemail.com> There should be a file called testlog somewhere, either at the toplevel or within the tests directory. Could you search for "apirecomp001" and send me the test output from running that test. I can't reproduce this failure when running it manually even though I'm on OS X, too. On 18 Mar 2009, at 10:51, Gregory Wright wrote: > > I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as > a bootstrap compiler. The build was done using the MacPorts > infrastructure. > > Summary test results: > > OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 > 2334 total tests, which gave rise to > 12487 test cases, of which > 0 caused framework failures > 2460 were skipped > > 9709 expected passes > 258 expected failures > 0 unexpected passes > 60 unexpected failures > > Unexpected failures: > 2469(ghci) > apirecomp001(normal) > > bits > (normal > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > conc049(hpc) > conc068(normal) > derefnull(profc,profthreaded) > divbyzero(profc,profthreaded) > > genUpTo > (normal > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) > > num009 > (normal > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > num012 > (normal > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > signals002(ghci) > signals004(ghci,threaded1,threaded2,profthreaded) > > > I haven't looked at the errors in detail, but generally the release > candidate > seems OK. > > BTW, a test target will be added to MacPorts's portfile for the > 6.10.2 release, which will > let you run the test suite by typing > > > sudo port test ghc > > and if you then install the tested build, a record of the test will > be saved in > $PREFIX/share/ghc-/. > > Best Wishes, > Greg > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users / Thomas -- Push the envelope. Watch it bend. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090318/2f91d79d/PGP.bin From colin at colina.demon.co.uk Wed Mar 18 10:28:07 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Mar 18 10:16:02 2009 Subject: Advice wanted on parallel processing Message-ID: I've just managed to build ghc 6.11 (Thanks Simon). I did this for two reasons, one of which is I want to try to improve the speed of the AI for the Chu Shogi program I am writing by making use of parallel processing. I have a 4-core Xeon runing Fedora Linux 10 (AMD64). I have a repeatable scenario for timings. With ghc 6.10.1, no threaded runtime, the computer takes 51 or 52 seconds to move (experimental variation up to 1.2 seconds). With ghc 6.11, it takes the same time. If I switch on the threaded runtime, then it rises slightly (perhaps not significantly - I measure 53-54 seconds). With 2, 3 or 4 processors, I measured (one-off, so not reliable) 65, 55 and 58 seconds respectively. Well, that doesn't really matter, provided I can get the time back with interest by exploiting parallelism. My first thought for an "easy" win is the move generator. At present I have this code: -- | Generate all legal moves from state. -- -- The best moves (according to some heuristic) should come first generate_moves :: (Non_interactive_state, Maybe Move) -> [(Non_interactive_state, Maybe Move)] generate_moves (state, _) = let colour = case is_black_to_play state of True -> Black False -> White pieces' = all_pieces_of_colour (board state) colour unsorted = concatMap (generate_moves_for_piece state) pieces' sorted = sortBy best_move unsorted moves = mapMaybe new_move sorted in {-trace (concat (intersperse "\n" (map (print_move . fromJust . snd) moves)))-} moves where new_move mv = case update_from_move (state, Nothing) mv of Nothing -> Nothing Just (st', Nothing) -> Just (st', Just mv) and my idea was to run the call to generate_moves_for_piece in parallel over the pieces' list. I thought I could do that simply by replacing concatMap with parFlatMap, but discovered I need to supply an extra argument - a Strategy. Not knowing what this should be (where's the best place to read up on this?) I tried specifying rwhnf. My timings then are: -N1 83 seconds -N2 57 seconds -N3 58 seconds -N4 60 seconds so a complete failure. Where should I go from here? -- Colin Adams Preston Lancashire From naur at post11.tele.dk Wed Mar 18 10:36:35 2009 From: naur at post11.tele.dk (Thorkil Naur) Date: Wed Mar 18 10:27:08 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 In-Reply-To: <2B2A5BDC-B4A7-4E2D-A42D-B190A0A9FDA2@googlemail.com> References: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> <2B2A5BDC-B4A7-4E2D-A42D-B190A0A9FDA2@googlemail.com> Message-ID: <200903181536.36337.naur@post11.tele.dk> Hello Thomas, On Wednesday 18 March 2009 15:03, Thomas Schilling wrote: > There should be a file called testlog somewhere, either at the > toplevel or within the tests directory. Could you search for > "apirecomp001" and send me the test output from running that test. I > can't reproduce this failure when running it manually even though I'm > on OS X, too. Several of the buildbot slaves fail the apirecomp001(normal) test as well. For eaxmple, here is the output from http://darcs.haskell.org/buildbot/all/builders/tnaur%20x86%20Linux%20head/builds/333/steps/runtestsuite/logs/unexpected for that test: =====> apirecomp001(normal) cd ./ghc-api/apirecomp001 && $MAKE -s --no-print-directory apirecomp001 apirecomp001.run.stdout 2>apirecomp001.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: make[1]: myghc: Command not found make[1]: *** [apirecomp001] Error 127 *** unexpected failure for apirecomp001(normal) > > On 18 Mar 2009, at 10:51, Gregory Wright wrote: > > > > > I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as > > a bootstrap compiler. The build was done using the MacPorts > > infrastructure. > > > > Summary test results: > > > > OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 > > 2334 total tests, which gave rise to > > 12487 test cases, of which > > 0 caused framework failures > > 2460 were skipped > > > > 9709 expected passes > > 258 expected failures > > 0 unexpected passes > > 60 unexpected failures > > > > Unexpected failures: > > 2469(ghci) > > apirecomp001(normal) > > > > bits > > (normal > > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > conc049(hpc) > > conc068(normal) > > derefnull(profc,profthreaded) > > divbyzero(profc,profthreaded) > > > > genUpTo > > (normal > > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) > > > > num009 > > (normal > > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > > > num012 > > (normal > > ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) > > signals002(ghci) > > signals004(ghci,threaded1,threaded2,profthreaded) > > > > > > I haven't looked at the errors in detail, but generally the release > > candidate > > seems OK. > > > > BTW, a test target will be added to MacPorts's portfile for the > > 6.10.2 release, which will > > let you run the test suite by typing > > > > > sudo port test ghc > > > > and if you then install the tested build, a record of the test will > > be saved in > > $PREFIX/share/ghc-/. > > > > Best Wishes, > > Greg > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > / Thomas > -- > Push the envelope. Watch it bend. > > > > Best regards Thorkil From daniel.is.fischer at web.de Wed Mar 18 10:41:13 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Mar 18 10:29:05 2009 Subject: Advice wanted on parallel processing In-Reply-To: References: Message-ID: <200903181541.13336.daniel.is.fischer@web.de> Am Mittwoch, 18. M?rz 2009 15:28 schrieb Colin Paul Adams: > I've just managed to build ghc 6.11 (Thanks Simon). > > I did this for two reasons, one of which is I want to try to improve > the speed of the AI for the Chu Shogi program I am writing by making > use of parallel processing. I have a 4-core Xeon runing Fedora Linux > 10 (AMD64). > > I have a repeatable scenario for timings. With ghc 6.10.1, no threaded > runtime, the computer takes 51 or 52 seconds to move (experimental > variation up to 1.2 seconds). > > With ghc 6.11, it takes the same time. > > If I switch on the threaded runtime, then it rises slightly (perhaps > not significantly - I measure 53-54 seconds). With 2, 3 or 4 > processors, I measured (one-off, so not reliable) 65, 55 and 58 > seconds respectively. > > Well, that doesn't really matter, provided I can get the time back > with interest by exploiting parallelism. My first thought for an > "easy" win is the move generator. At present I have this code: > > -- | Generate all legal moves from state. > -- > -- The best moves (according to some heuristic) should come first > generate_moves :: (Non_interactive_state, Maybe Move) -> > [(Non_interactive_state, Maybe Move)] generate_moves (state, _) = > let colour = case is_black_to_play state of > True -> Black > False -> White > pieces' = all_pieces_of_colour (board state) colour > unsorted = concatMap (generate_moves_for_piece state) pieces' > sorted = sortBy best_move unsorted > moves = mapMaybe new_move sorted > in {-trace (concat (intersperse "\n" (map (print_move . fromJust . snd) > moves)))-} moves where new_move mv = > case update_from_move (state, Nothing) mv of > Nothing -> Nothing > Just (st', Nothing) -> Just (st', Just mv) > > > and my idea was to run the call to generate_moves_for_piece in > parallel over the pieces' list. I thought I could do that simply by > replacing concatMap with parFlatMap, but discovered I need to supply > an extra argument - a Strategy. Not knowing what this should be > (where's the best place to read up on this?) I tried specifying rwhnf. Control.Parallel.Strategies, docs and source? generate_moves_for_piece produces a list. rwhnf forces this list enough to see if it's [] or (_:_) (rwhnf x = x `seq` ()), that doesn't get enough work done in each thread to compensate the overhead. Try using rnf after writing an NFData instance for Move. If e.g. data Move = Move {from :: Position, to :: Position} , the instance would be instance NFData Move where rnf (Move f t) = rnf f `seq` rnf t `seq` () That might require NFData instances for Position and its components, but specifying these should be automatic. > > My timings then are: > > -N1 83 seconds > -N2 57 seconds > -N3 58 seconds > -N4 60 seconds > > so a complete failure. > > Where should I go from here? HTH, Daniel From gwright at comcast.net Wed Mar 18 11:22:43 2009 From: gwright at comcast.net (Gregory Wright) Date: Wed Mar 18 11:11:16 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 In-Reply-To: <2B2A5BDC-B4A7-4E2D-A42D-B190A0A9FDA2@googlemail.com> References: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> <2B2A5BDC-B4A7-4E2D-A42D-B190A0A9FDA2@googlemail.com> Message-ID: Hi Thomas, On Mar 18, 2009, at 10:03 AM, Thomas Schilling wrote: > There should be a file called testlog somewhere, either at the > toplevel or within the tests directory. Could you search for > "apirecomp001" and send me the test output from running that test. > I can't reproduce this failure when running it manually even though > I'm on OS X, too. > I get: ====> Running ./ghc-api/apirecomp001/all.T =====> apirecomp001(normal)cd ./ghc-api/apirecomp001 && $MAKE -s --no- print-directory apirecomp001 apirecomp001.run.stdout 2>apirecomp001.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ld warning: atom sorting error for _ghczm6zi10zi1zi20090314_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1zi20090314_LibFFI_Czuffizucif_closure_tbl in /opt/local/ var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc- beta/work/ghc-6.10.1.20090314/compiler/dist-stage2/build/ libHSghc-6.10.1.20090314.a(LibFFI.o) ld warning: atom sorting error for _ghczm6zi10zi1zi20090314_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi1zi20090314_LibFFI_Czuffizucif_closure_tbl in /opt/local/ var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc- beta/work/ghc-6.10.1.20090314/compiler/dist-stage2/build/ libHSghc-6.10.1.20090314.a(LibFFI.o) make[2]: myghc: Command not found make[2]: *** [apirecomp001] Error 127 *** unexpected failure for apirecomp001(normal) Best Wishes, Greg From igloo at earth.li Wed Mar 18 13:53:39 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Mar 18 13:41:33 2009 Subject: Under Solaris: GHC 6.10.2 Release Candidate 1 In-Reply-To: <1237336130.22402.577.camel@localhost> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> <49BF76D1.4060508@dfki.de> <1237336130.22402.577.camel@localhost> Message-ID: <20090318175339.GA19406@matrix.chaos.earth.li> On Wed, Mar 18, 2009 at 12:28:50AM +0000, Duncan Coutts wrote: > On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote: > > > > unix >= 2.0 && < 2.4 > > > > Changing to "<= 2.4" was not sufficient, so I changed it to "<= 2.5". > > This will affect any OS! > > Hmm, it's a bit suspicious that the major version number is changing in > a minor ghc release. Do we know what the API breakage is? This could > affect any program. This looks like a braino to me. Things have been added to the API, but I don't see anything that's been removed or change. I'll put the version number back to 2.3.2.0. Thanks Ian From colin at colina.demon.co.uk Wed Mar 18 16:34:02 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Mar 18 16:21:56 2009 Subject: Advice wanted on parallel processing In-Reply-To: <200903181541.13336.daniel.is.fischer@web.de> (Daniel Fischer's message of "Wed\, 18 Mar 2009 15\:41\:13 +0100") References: <200903181541.13336.daniel.is.fischer@web.de> Message-ID: >>>>> "Daniel" == Daniel Fischer writes: Daniel> generate_moves_for_piece produces a list. rwhnf forces Daniel> this list enough to see if it's [] or (_:_) (rwhnf x = x Daniel> `seq` ()), that doesn't get enough work done in each Daniel> thread to compensate the overhead. Try using rnf after Daniel> writing an NFData instance for Move. Daniel> If e.g. Daniel> data Move = Move {from :: Position, to :: Position} Daniel> , the instance would be Daniel> instance NFData Move where rnf (Move f t) = rnf f `seq` Daniel> rnf t `seq` () It made no difference to the timings whatsoever. Anyway, at that point I decided to revert to the first rule of performance tuning, and profiled the program for time. The move generator was using less than 3% of the cpu time, so that was clearly a waste of time on my part. The one routine that stood out was this one (about 35% CPU time, with 0% attributed to children): -- | Value of one rank of the board rank_value :: (Int, Array Int Square) -> Int rank_value (rank_coord, rank') = sum (map (cell_value rank_coord) (assocs rank')) The array has 12 elements. So I tried changing the map to parMap rnf. This gave timings of: >> -N1 93 seconds -N2 105 seconds -N3 206 seconds at which point I decided I hadn't got a clue what was going on. -- Colin Adams Preston Lancashire From allbery at ece.cmu.edu Wed Mar 18 16:51:44 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Mar 18 16:39:50 2009 Subject: Advice wanted on parallel processing In-Reply-To: References: <200903181541.13336.daniel.is.fischer@web.de> Message-ID: <2EF7F7B6-539C-46D6-A816-D0B4F6B392FF@ece.cmu.edu> On 2009 Mar 18, at 16:34, Colin Paul Adams wrote: > The one routine that stood out was this one (about 35% CPU time, with > 0% attributed to children): > > > -- | Value of one rank of the board > rank_value :: (Int, Array Int Square) -> Int > rank_value (rank_coord, rank') = sum (map (cell_value rank_coord) > (assocs rank')) > > The array has 12 elements. How many times do you call it? Perhaps the real optimization you need is to memoize. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090318/34cbcadc/PGP-0001.bin From colin at colina.demon.co.uk Wed Mar 18 16:59:54 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Wed Mar 18 16:47:48 2009 Subject: Advice wanted on parallel processing In-Reply-To: <2EF7F7B6-539C-46D6-A816-D0B4F6B392FF@ece.cmu.edu> (Brandon S. Allbery's message of "Wed\, 18 Mar 2009 16\:51\:44 -0400") References: <200903181541.13336.daniel.is.fischer@web.de> <2EF7F7B6-539C-46D6-A816-D0B4F6B392FF@ece.cmu.edu> Message-ID: >>>>> "Brandon" == Brandon S Allbery KF8NH writes: >> The array has 12 elements. Brandon> How many times do you call it? Perhaps the real Brandon> optimization you need is to memoize. Very many times indeed. But it is a different array on most occasions (I am not updating in place). It represents one rank of the board on which the game is played. The move generator produces a new board for each move. -- Colin Adams Preston Lancashire From allbery at ece.cmu.edu Wed Mar 18 19:19:09 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Mar 18 19:07:14 2009 Subject: Advice wanted on parallel processing In-Reply-To: References: <200903181541.13336.daniel.is.fischer@web.de> <2EF7F7B6-539C-46D6-A816-D0B4F6B392FF@ece.cmu.edu> Message-ID: On 2009 Mar 18, at 16:59, Colin Paul Adams wrote: >>>>>> "Brandon" == Brandon S Allbery KF8NH >>>>>> writes: > >>> The array has 12 elements. > > Brandon> How many times do you call it? Perhaps the real > Brandon> optimization you need is to memoize. > > Very many times indeed. But it is a different array on most occasions > (I am not updating in place). > > It represents one rank of the board on which the game is played. The > move generator produces a new board for each move. It might be helpful for you to show more of the program. One thing to keep in mind about parallelization is that the level at which happens matters: if individual calculations across the list are fast, all you gain by parallelizing it is MP synchronization/locking overhead. On the other hand, it's possible that if the caller can be rearranged so that rank_value is computed on another CPU while it's doing something else, you could gain quite a bit. Or maybe the caller is itself at the right level to parallelize. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090318/4072456f/PGP.bin From claus.reinke at talk21.com Wed Mar 18 20:18:29 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 18 20:06:27 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> Message-ID: <1064B0BBEFC04EC880CDB86288D0360D@cr3lt> Recursion unfolding spec, 2nd attempt. The main difference is to look at groups of mutually recursive definitions as a whole, rather than trying to think about individual definitions. That step actually seems sufficient to address most of the shortcomings raised so far, such as avoiding runaway INLINE or using PEEL/UNROLL also for mutually recursive definitions. I've also interpreted Max's comments as most of the existing INLINE restriction still making sense for recursive INLINE, with small clarifications. In the following, let REC({f g ..}) denote the set of all identifiers belonging to the recursion involving f, g, .. (f, g, .. in REC({f g ..}) or in {-# INLINE f g .. #-} are required to belong to the same recursion). {-# NOINLINE f #-} as now: no unfolding of f {-# INLINE f #-} as now: for non-recursive f only, unfold definition of f at call sites of f (might in future be taken as go-ahead for analysis-based recursion unfolding) {-# INLINE f g .. PEEL n #-} new: unfold definitions of the named identifiers at their call sites *outside* their recursion group REC({f g ..}). In other words, *entries into* REC({f g ..}) via f, g, .. are unfolded. (for the special case of loops this corresponds to loop peeling) {-# INLINE f g .. UNROLL m #-} new: unfold definitions of the named identifiers at their call sites *inside* their recursion group REC({f g ..}). In other words, *cross-references inside* REC({f g ..}) via f, g, .. are unfolded. (for the special case of loops this corresponds to loop unrolling) {-# INLINE f g .. PEEL n UNROLL m #-} combine the previous two The numeric parameters are to be interpreted as if each call to f, g, .. was annotated with both PEEL and UNROLL limits for the whole recursion group REC({f g ..}), starting with the limits from the pragmas (write f_n_m for a call to f with PEEL limit n and UNROLL limit m), to be decreased for every PEEL or UNROLL action, as follows (REC({f g}) = {f g h}, in these examples): 1. let {-# INLINE f g PEEL n UNROLL m #-} f .. = .. f_?_? .. g_?_? .. h_0_0 .. g .. = .. f_?_? .. g_?_? .. h_0_0 .. h .. = .. f_?_? .. g_?_? .. h_0_0 .. in ..|f_n_m|.. --PEEL--> let {-# INLINE f g PEEL n UNROLL m #-} f .. = .. f_?_? .. g_?_? .. h_0_0 .. g .. = .. f_?_? .. g_?_? .. h_0_0 .. h .. = .. f_?_? .. g_?_? .. h_0_0 .. in ..|.. f_(n-1)_0 .. g_(n-1)_0 .. h_0_0 ..|.. Notes: - unfolding produces copies of definition bodies - the PEEL limit at the call site decides the PEEL limit for all calls to REC({f g}) in the inlined copy; this limit decreases with each PEEL step - since peeling unfolds code into call sites from outside the recursion, the UNROLL limits of calls to REC({f g}) are effectively 0 in the inlined copy - only calls to identifiers named in the INLINE pragma can be peeled (f and g here), calls to other members of the same recursion remain unaffected (h here), having effective limits of 0 2. let {-# INLINE f g PEEL n UNROLL m #-} f .. = .. f_0_m .. g_?_? .. h_0_0 .. g .. = .. f_?_? .. g_?_? .. h_0_0 .. h .. = .. f_?_? .. g_?_? .. h_0_0 .. in .. --UNROLL--> let {-# INLINE f g PEEL n UNROLL m #-} f .. = .. .. f_0_(m-1) .. g_0_(m-1) .. h_0_0 .. .. g_?_? .. h_0_0 .. g .. = .. f_?_? .. g_?_? .. h_0_0 .. h .. = .. f_?_? .. g_?_? .. h_0_0 .. in .. Notes: - unfolding produces copies of definition bodies - the UNROLL limit at the call site decides the UNROLL limit for all calls to REC({f g}) in the inlined copy; this limit decreases with each UNROLL step - peeling conceptually precedes unrolling (PEEL limit needs to reach 0 before unrolling commences), to avoid peeling unrolled definitions (this corresponds to an existing restriction of no inlining into definitions to be inlined; - unrolling unfolds copies of the original definitions, not the already unrolled ones, again corresponding to the existing inlining restriction (TODO: how to specify this avoidance of unrolling unrolled defs in this form of local rule spec?) - only calls to identifiers named in the INLINE pragma can be unrolled (f and g here), calls to other members of the same recursion remain unaffected (h here), having effective limits of 0 Peeling and unrolling stop when the respective count annotation has reached 0. Peeling precedes unrolling, to avoid ambiguities in the size of the peeled definitions. Note that mutual recursion is the domain of PEEL, while UNROLL only applies to (mutual) recursion. {-# INLINE f PEEL n #-}, for n>0, corresponds to worker/ wrapper transforms (previously done manually) + inline wrapper, and should therefore also be taken as a hint for the compiler to try the static argument transformation for f (the "worker"). Non-supporting implementations should treat these as INLINE pragmas (same warning/ignore or automatic unfold behaviour). This might be easier to accomplish if INLINE PEEL/UNROLL were implemented as separate pragmas, even though they are refinements of INLINE conceptually. About the current side-conditions for INLINE pragmas: - no functions inlined into f: still makes sense for PEEL, needs to be adapted with an exception for UNROLL, in that we want to be able to unroll into the function being unrolled, but we want to use the original body for the unrolling, not an already unrolled one (else unrolling would be exponential rather than linear); this appears to be in line with existing work on INLINE - no float-in/float-out/cse: similar to existing INLINE - no worker/wrapper transform in strictness analyser: similar to existing INLINE - loop breakers: PEEL/UNROLL have their own limits, applicable to the whole recursion group, creating intrinsic loop breakers when the counters run out. Every PEEL or UNROLL action creates calls with smaller counters in the inlined copies, if the calls go into the same recursion. If this is an improvement on the first version, and after correcting any obvious issues, I should put it on the ghc trac wiki somewhere, and create a feature request ticket. Claus From waldmann at imn.htwk-leipzig.de Wed Mar 18 20:37:05 2009 From: waldmann at imn.htwk-leipzig.de (j.waldmann) Date: Wed Mar 18 20:24:57 2009 Subject: Advice wanted on parallel processing In-Reply-To: References: <200903181541.13336.daniel.is.fischer@web.de> <2EF7F7B6-539C-46D6-A816-D0B4F6B392FF@ece.cmu.edu> Message-ID: <22591720.post@talk.nabble.com> > (I am not updating in place). > The move generator produces a new board for each move. Well, this is sound design, but current memory managers may not be up to it. If you check the (board) game programming literature, you'll find that engine authors take great efforts to bypass automatic memory management (do all updates on the "current" board in-place, and write their own malloc/free for game tree nodes). This becomes even more important when trying to exploit concurrency. In theory, that's all very nice (you can evaluate independent branches of the game tree in parallel) but in practice, you're doomed if your memory allocator/collector is still essentially single-threaded (that is, blocks all threads). That's language independent (it's a property of the run-time system). Of course in a more declarative language it should be easier for the compiler to analyze the source code and replace malloc/free by something better (no allocation by immediate re-use, or easy deallocation by some stack regime). J.W. -- View this message in context: http://www.nabble.com/Advice-wanted-on-parallel-processing-tp22580444p22591720.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From igloo at earth.li Wed Mar 18 20:37:40 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Mar 18 20:25:33 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <49BE293D.9020709@centrum.cz> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE293D.9020709@centrum.cz> Message-ID: <20090319003740.GA1157@matrix.chaos.earth.li> Hi Karel, On Mon, Mar 16, 2009 at 11:26:05AM +0100, Karel Gardas wrote: > > interesting but I'm not able to build this on SunOS 5.11/x86. The build > fails with: > > (echo dist/build/cbits/PrelIOUtils.p_o dist/build/cbits/WCsubst.p_o > dist/build/cbits/Win32Utils.p_o dist/build/cbits/consUtils.p_o > dist/build/cbits/dirUtils.p_o dist/build/cbits/inputReady.p_o > dist/build/cbits/selectUtils.p_o `find dist/build -name "*_stub.p_o" > -print`; find dist/build/Foreign/Concurrent_split > dist/build/GHC/Arr_split dist/build/GHC/Base_split [...] > dist/build/Text/Show/Functions_split dist/build/Unsafe/Coerce_split > -name '*.p_o' -print) | xargs /usr/bin/ar q > dist/build/libHSbase-4.1.0.0_p.a > ar: creating dist/build/libHSbase-4.1.0.0_p.a > internal error: error_message(58) > gmake[3]: *** [dist/build/libHSbase-4.1.0.0_p.a] Error 100 > gmake[2]: *** [all] Error 1 > gmake[2]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries/base' > gmake[1]: *** [make.library.base] Error 2 > gmake[1]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/libraries' > gmake: *** [stage1] Error 2 > > I've configure with simple: > ./configure --prefix=/tmp/ghc-6.10.1.20090314 > > and build with: > > gmake > > The interesting thing is that GHC stable builds on my buildbot well: > http://darcs.haskell.org/buildbot/all/builders/kgardas%20stable The buildbot is putting "SplitObjs=NO" in mk/build.mk. The above log has object splitting enabled, which means that there are a lot more .o files, which is presumably causing some problem with your ar. If you have both a GNU ar and a Solaris ar then it might be worth seeing if the other one works. Otherwise, putting "SplitObjs=NO" in mk/build.mk will work, but at the expense of larger binaries. Thanks Ian From claus.reinke at talk21.com Wed Mar 18 20:43:04 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 18 20:31:01 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <84586116-A34E-4980-B5DD-974AAE54DE61@cse.unsw.edu.au> Message-ID: <07D905592C524EF7AF69EABF3C37E6D8@cr3lt> >> {-# INLINE f PEEL n UNROLL m #-} > > The problem here is that this only works for directly recursive > functions which I, for instance, don't normally use in high- > performance code. Most of my loops are pipelines of collective > combinators like map, filter, fold etc. because these are the ones > that can be fused automatically. Unless I'm misunderstanding > something, this approach doesn't handle such cases. If the map, filter, fold, etc can be unrolled, then the unrolled definitions would be fused, right? So what is missing is fine control ("how much to unroll this particular call to map here"). Would it help to allow {-# INLINE map PEEL n UNROLL m #-} in the caller modules as well as the definition modules, with the latter providing a general case/upper limit, and the former providing finer control? If you wanted even finer control, one would need a way to specify named copies of inlineable recursion combinators, with PEEL/UNROLL attached to the copies.. I see how this would need addressing, but I don't yet see a good way to specify call-site-specific PEEL/UNROLL for recursion combinators. Unless you want to control it by adding combinators for the purpose?-) Claus From dons at galois.com Wed Mar 18 20:54:05 2009 From: dons at galois.com (Don Stewart) Date: Wed Mar 18 20:42:56 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090315235327.GA21375@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> <20090315224920.GA23101@bach> <20090315235327.GA21375@matrix.chaos.earth.li> Message-ID: <20090319005405.GG6834@whirlpool.galois.com> I've tried the 6.10.2 RC with some performance-sensitive work code. The code uses the non-threaded runtime, and makes extensive use of signals. The results look very good. The slightly funny (but useful to us) benchmark measures bandwidth communicating between multiple unix processes. Here's a graph of how much better 6.10.2 is doing: http://galois.com/~dons/images/bandwidth.png Note we're over a 1G/s bandwidth now with 6.10.2 for the first time :) Thanks guys! (Note also we use a slightly modified runtime that has thread deadlock detection disabled). There have been quite a few runtime patches, enough that 6.10.2 is really quite a different runtime now: http://galois.com/~dons/rts.patches http://galois.com/~dons/6101-6102.diff Anyway, all those signal and thread handling changes are looking good. -- Don From jnf at arcor.de Thu Mar 19 00:21:25 2009 From: jnf at arcor.de (jutaro) Date: Thu Mar 19 00:09:19 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090315155142.GA18000@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> Message-ID: <22592804.post@talk.nabble.com> I've installed a GUI application based on gtk2hs. It frequently crashes with the error: leksah: error: a C finalizer called back into Haskell. use Foreign.Concurrent.newForeignPtr for Haskell finalizers. This error did never occur with the 6.10 released version. It was verified that this happens on different machines. I've no idea how to isolate this bug. Any idea about this? J?rgen Nicklisch-Franken Ian Lynagh wrote: > > > We are pleased to announce the first release candidate for GHC 6.10.2: > > http://www.haskell.org/ghc/dist/6.10.2-rc1/ > > This includes two source bundles: > > ghc-6.10.1.20090314-src.tar.bz2 > ghc-6.10.1.20090314-src-extralibs.tar.bz2 > > Only the first of these is necessary. The "extralibs" package contains > various extra packages that we normally supply with GHC - unpack the > extralibs tarball on top of the source tree to add them, and they will > be included in the build automatically. > > There are also installers for Windows (i386) and OS X (i386), and binary > distributions for x86_64/Linux and i386/Linux. More may appear later. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks > Ian, on behalf of the GHC team > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22592804.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From colin at colina.demon.co.uk Thu Mar 19 02:35:28 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Thu Mar 19 02:23:21 2009 Subject: Advice wanted on parallel processing In-Reply-To: <22591720.post@talk.nabble.com> (j. waldmann's message of "Wed\, 18 Mar 2009 17\:37\:05 -0700 \(PDT\)") References: <200903181541.13336.daniel.is.fischer@web.de> <2EF7F7B6-539C-46D6-A816-D0B4F6B392FF@ece.cmu.edu> <22591720.post@talk.nabble.com> Message-ID: >>>>> ">" == j waldmann writes: >> (I am not updating in place). The move generator produces a >> new board for each move. >> Well, this is sound design, but current memory managers may not >> be up to it. If you check the (board) game programming >> literature, you'll find that engine authors take great efforts >> to bypass automatic memory management (do all updates on the >> "current" board in-place, and write their own malloc/free for >> game tree nodes). I know it. In fact I wrote a program for this game about 10 years ago, in C++, which did all updates in place. It wasn't very good (although being the only one that implemented the rules correctly - as far as I could tell - they are very complicated - was necessarily the best). Now I want to have another go in Haskell. Reading about DPH inspired me to give it a try, although I'm not attempting to use DPH yet. Probably I was too naive thinking I was going to be able to exploit parallelism without pain. >> This becomes even more important when trying to exploit >> concurrency. In theory, that's all very nice (you can evaluate >> independent branches of the game tree in parallel) but in >> practice, you're doomed if your memory allocator/collector is >> still essentially single-threaded (that is, blocks all >> threads). OK, that's interesting. GHC's collector is still stop-the-world at the moment, right? I read in the recent paper that it is intended to try to remedy that soon, in which case I can try again to see if that improves matters. -- Colin Adams Preston Lancashire From colin at colina.demon.co.uk Thu Mar 19 02:46:06 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Thu Mar 19 02:34:00 2009 Subject: Advice wanted on parallel processing In-Reply-To: (Brandon S. Allbery's message of "Wed\, 18 Mar 2009 19\:19\:09 -0400") References: <200903181541.13336.daniel.is.fischer@web.de> <2EF7F7B6-539C-46D6-A816-D0B4F6B392FF@ece.cmu.edu> Message-ID: >>>>> "Brandon" == Brandon S Allbery KF8NH writes: Brandon> On 2009 Mar 18, at 16:59, Colin Paul Adams wrote: >>>>>>> "Brandon" == Brandon S Allbery KF8NH >>>>>>> writes: >> >>>> The array has 12 elements. >> Brandon> How many times do you call it? Perhaps the real Brandon> optimization you need is to memoize. >> >> Very many times indeed. But it is a different array on most >> occasions (I am not updating in place). >> >> It represents one rank of the board on which the game is >> played. The move generator produces a new board for each move. Brandon> It might be helpful for you to show more of the program. I'm not sure which bits to show that might be revealing. The whole thing can be seen by darcs pull http://code.haskell.org/srv/code/chu-shogi/ if you are particularly interested. Board.hs is where rank_value is to be found. You would also need darcs pull http://code.haskell.org/srv/code/game-tree/ Brandon> One thing to keep in mind about parallelization is that Brandon> the level at which happens matters: if individual Brandon> calculations across the list are fast, all you gain by Profiling shows that nearly all the time is spent in evaluating the position. I'm doing that (at the moment) by evaluating each square in isolation (that might change in the future), then summing each rank, and then summing the ranks. Brandon> parallelizing it is MP synchronization/locking overhead. Brandon> On the other hand, it's possible that if the caller can Brandon> be rearranged so that rank_value is computed on another Brandon> CPU while it's doing something else, you could gain quite Brandon> a bit. Or maybe the caller is itself at the right level Brandon> to parallelize. So at first glance it looked as if the calculation for each rank (and indeed each cell) should be able to proceed completly independently of each other. But the profile shows no time allocated to the children of rank_value (although cell_value, which is called by it, uses a lot of time). So my intution seems defeated. perhaps by code-rewriting, although I can't imagine how. -- Colin Adams Preston Lancashire From batterseapower at hotmail.com Thu Mar 19 04:37:43 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Thu Mar 19 04:25:36 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <07D905592C524EF7AF69EABF3C37E6D8@cr3lt> References: <20090228174932.GA23519@whirlpool.galois.com> <26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> <9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com> <35DD9685B0814863B1379F2995C81F8C@cr3lt> <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <84586116-A34E-4980-B5DD-974AAE54DE61@cse.unsw.edu.au> <07D905592C524EF7AF69EABF3C37E6D8@cr3lt> Message-ID: <9d4d38820903190137r7991c452h3f117ebffb4edcd@mail.gmail.com> 2009/3/19 Claus Reinke : > If the map, filter, fold, etc can be unrolled, then the unrolled > definitions would be fused, right? So what is missing is fine > control ("how much to unroll this particular call to map here"). The issues is that In stream fusion the combinators like "map" are all non-recursive and so unrolling/peeling doesn't make any sense. In fact, their being non-recursive is almost the whole point, because it lets GHC inline them like crazy and hence build a nice efficient fused pipeline of combinators eventually. The recursion is introduced purely in one place - unstream - and even then it doesn't go through unstream but through a locally recursive wrapper (so GHC can see the structure of the stream). So, it might be sufficient if: 1) You changed stream fusion so unstream was directly recursive, but added an INLINE PEEL 1 annotation to it, so if the call site doesn't do any unrollling at least you will still be able to spot the structure of the stream 2) You could, at the call site, add an INLINE PEEL 1 UNROLL n annotation that took the /original/ RHS for unstream and unrolled it however many times the user specifies (you still need a PEEL 1 so you can spot the stream structure in the unrolled loop) Unfortunately, this all feels quite fragile :-( Max From simonmar at microsoft.com Thu Mar 19 04:59:42 2009 From: simonmar at microsoft.com (Simon Marlow) Date: Thu Mar 19 04:47:34 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090319005405.GG6834@whirlpool.galois.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <20090315224920.GA23101@bach> <20090315235327.GA21375@matrix.chaos.earth.li> <20090319005405.GG6834@whirlpool.galois.com> Message-ID: <1C6E59C47F062E42820BEE74FD3388E9230C97F687@EA-EXMSG-C333.europe.corp.microsoft.com> > I've tried the 6.10.2 RC with some performance-sensitive work code. > The code uses the non-threaded runtime, and makes extensive use of > signals. The results look very good. > > The slightly funny (but useful to us) benchmark measures bandwidth > communicating between multiple unix processes. Here's a graph of how > much better 6.10.2 is doing: > > http://galois.com/~dons/images/bandwidth.png > > Note we're over a 1G/s bandwidth now with 6.10.2 for the first time :) > Thanks guys! > > (Note also we use a slightly modified runtime that has thread deadlock > detection disabled). > > There have been quite a few runtime patches, enough that 6.10.2 is > really quite a different runtime now: > > http://galois.com/~dons/rts.patches > http://galois.com/~dons/6101-6102.diff > > Anyway, all those signal and thread handling changes are looking good. Looking back through what has gone into 6.10.2, I think the credit probably goes to the patch below. It's nice to hear this improves performance too - that was an unexpected benefit. If you're able to test with the HEAD, I'd be very interested to see your results there too. Cheers, Simon Fri Feb 20 14:32:00 GMT 2009 Ian Lynagh * MERGED: Rewrite of signal-handling (ghc patch; see also base and unix patches) Simon Marlow **20090219103142 Ignore-this: aca7c3e258224fadc6f0f2fee86b2971 The API is the same (for now). The new implementation has the capability to define signal handlers that have access to the siginfo of the signal (#592), but this functionality is not exposed in this patch. #2451 is the ticket for the new API. The main purpose of bringing this in now is to fix race conditions in the old signal handling code (#2858). Later we can enable the new API in the HEAD. Implementation differences: - More of the signal-handling is moved into Haskell. We store the table of signal handlers in an MVar, rather than having a table of StablePtrs in the RTS. - In the threaded RTS, the siginfo of the signal is passed down the pipe to the IO manager thread, which manages the business of starting up new signal handler threads. In the non-threaded RTS, the siginfo of caught signals is stored in the RTS, and the scheduler starts new signal handler threads. From batterseapower at hotmail.com Thu Mar 19 05:06:47 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Thu Mar 19 04:54:39 2009 Subject: Loop unrolling + fusion ? In-Reply-To: <1064B0BBEFC04EC880CDB86288D0360D@cr3lt> References: <20090228174932.GA23519@whirlpool.galois.com> <26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt> <9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com> <35DD9685B0814863B1379F2995C81F8C@cr3lt> <9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com> <1064B0BBEFC04EC880CDB86288D0360D@cr3lt> Message-ID: <9d4d38820903190206w1dfa820byb5349810844e3f3d@mail.gmail.com> 2009/3/19 Claus Reinke : > Recursion unfolding spec, 2nd attempt. > > .... > > If this is an improvement on the first version, and after correcting any > obvious issues, I should put it on the ghc trac wiki somewhere, and create a > feature request ticket. I can't see any issues with this version of the spec. I think in the implementation it makes most sense to do this as a core2core pass at an early stage in the pipeline, probably via plugins (so will have to wait until I get those into HEAD). In the case of PEEL, we don't want to identify all call sites directly and do the substitution in the pass so we should just output some bindings which will certainly be inlined into call sites later on. So, the transformation should be bottom up on the Core syntax tree and when it meets a recursive group of bindings we should do something like this: {-# INLINE f g PEEL 3 UNROLL 2 #-} f = ... g ... f ... h ... g = ... g ... f ... h ... h = ... g ... f ... h ... =(my pass)=> -- Temporary copies of f and g - dead code f_old = ... g_old ... f_old ... h ... g_old = ... g_old ... f_old ... h ... -- H unchanged for now, might get PEELed stuff inlined later h = ... g .. f ... h ... -- Top level unrolled definiiton - if we weren't doing peeling, these would be the new f and g f_unrolled = ... g_unrolled_1 ... f_unrolled_1 ... h ... g_unrolled = ... g_unrolled_1 ... f_unrolled_1 ... h ... -- Unrolled iteration. Will get inlined into f_unrolled / g_unrolled soon {-# INLINE f_unrolled_1 g_unrolled_1 #-} f_unrolled_1 = ... g_unrolled ... f_unrolled ... h ... g_unrolled_1 = ... g_unrolled ... f_unrolled ... h ... -- One level of peeling {-# INLINE f_1 g_1 #-} f_1 = ... g_unrolled ... f_unrolled ... h ... g_1 = ... g_unrolled ... f_unrolled ... h ... -- Second level of peeling {-# INLINE f_2 g_2 #-} f_2 = ... g_1 ... f_1 ... h ... g_2 = ... g_1 ... f_1 ... h ... -- Final level of peeling and new definitions for f and g. Inline pragmas -- make sure all of this gets inlined at the call site {-# INLINE f g #-} f = ... g_2 ... f_2 ... h ... g = ... g_2 ... f_2 ... h ... =(after the simplifier has run - effectively - there are a few harmless lies here)=> -- NB: I haven't shown inlining of the new f and g here, but it /will/ happen h = ... g .. f ... h ... -- I've inlined the inner unrolled iteration at every /call site/ within the top level unrolled iteration, as per -- the pragmas. Noone actualy calls this unrolled thing directly though, since we used PEEL as well f_unrolled = ... (... g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ... f_unrolled ... h ...) ... h ... g_unrolled = ... (... g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ... f_unrolled ... h ...) ... h ... -- This huge chunk of code gets inlined at every call site, which in turn call through to the unrolled bodies {-# INLINE f g #-} f = ... (... (... g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ... f_unrolled ... h ...) ... h ...) ... (... (... g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ... f_unrolled ... h ...) ... h ...) ... h ... g = ... (... (... g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ... f_unrolled ... h ...) ... h ...) ... (... (... g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ... f_unrolled ... h ...) ... h ...) ... h ... By ensuring that f and g are tagged INLINE we get the existing INLINE restrictions automatically in later Core passes. I think that this example transformation matches your spec - am I right? Cheers, Max From claus.reinke at talk21.com Wed Mar 18 20:59:53 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Mar 19 05:04:07 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com> <49B12BC5.8090008@gmail.com> <49B5323F.6040601@gmail.com> Message-ID: <10E0A28816474228ABE623FD1CDF19D1@cr3lt> Dear Simon*, thanks for answering my concerns about -fvia-C replacement. Are these answers somewhere in the ghc wiki, or perhaps they'd make a good basis for a useful ghc blog post? So, -fasm will soon be up to speed with -fvia-C in all cases, new native backends are not more difficult than more mangler branches, and tools for generating wrappers for CPP-based APIs should be provided. Just one additional point re: > We haven't had a single new registerised port of GHC in many years now. Interest in new platforms is increasing again, though. People have been talking about PS3, internet tablets, multicore machines, .. Personally, I'd like to be able to use GHC on, or at least for, coming smartphone generations, etc. (I don't see myself looking at native backends there, but probably I wouldn't have braved the mangler, either; still, someone else might prefer one over the other). And I don't understand how people can be happy with unregisterised GHC ports for long, given how many optimizations GHC is not doing even in best form!-) Thanks again, Claus From karel.gardas at centrum.cz Thu Mar 19 06:31:33 2009 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu Mar 19 06:19:07 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090319003740.GA1157@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE293D.9020709@centrum.cz> <20090319003740.GA1157@matrix.chaos.earth.li> Message-ID: <49C21F05.4040409@centrum.cz> Hi Ian, Ian Lynagh wrote: > The buildbot is putting "SplitObjs=NO" in mk/build.mk. The above log has > object splitting enabled, which means that there are a lot more .o > files, which is presumably causing some problem with your ar. > > If you have both a GNU ar and a Solaris ar then it might be worth seeing > if the other one works. Otherwise, putting "SplitObjs=NO" in mk/build.mk > will work, but at the expense of larger binaries. I put just GNU ar into my PATH, so GHC build is using Sun ld and GNU ar and the build runs for much longer and breaks on: Building hsc2hs-0.67... [1 of 2] Compiling Paths_hsc2hs ( dist-install/build/autogen/Paths_hsc2hs.hs, dist-install/build/hsc2hs/hsc2hs-tmp/Paths_hsc2hs.o ) [2 of 2] Compiling Main ( Main.hs, dist-install/build/hsc2hs/hsc2hs-tmp/Main.o ) Linking dist-install/build/hsc2hs/hsc2hs ... gmake[3]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/utils/hsc2hs' gmake -C haddock install-inplace gmake[3]: Entering directory `/var/tmp/ghc-6.10.1.20090314/utils/haddock' /var/tmp/ghc-6.10.1.20090314/utils/installPackage/install-inplace/bin/installPackage install '/var/tmp/ghc-6.10.1.20090314/utils/ghc-pkg/install-inplace/bin/ghc-pkg' '/var/tmp/ghc-6.10.1.20090314/inplace-datadir/package.conf' '' \ '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \ '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \ '$prefix/bin' \ '$prefix/lib' \ '$prefix/libexec' \ '$prefix/dynlib' \ '$prefix/share' \ '$prefix/doc' \ '$prefix/html' \ '$prefix/haddock' \ --distpref dist-install \ --enable-shell-wrappers Installing library in /var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace/lib/haddock-2.4.2 Installing executable(s) in /var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace/bin internal error: error_message(28) gmake[3]: *** [install-inplace] Error 100 gmake[3]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/utils/haddock' gmake[2]: *** [with-stage-2] Error 2 gmake[2]: Leaving directory `/var/tmp/ghc-6.10.1.20090314/utils' gmake[1]: *** [stage2] Error 2 gmake[1]: Leaving directory `/var/tmp/ghc-6.10.1.20090314' gmake: *** [bootstrap2] Error 2 The message `internal error: error_message(28)' looks suspiciously, is there any Sun ar invoked behind the scene? Or isn't this message from the AR but coming from something else? Thanks, Karel From marlowsd at gmail.com Thu Mar 19 06:51:23 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Mar 19 06:39:22 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <22592804.post@talk.nabble.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> Message-ID: <49C223AB.2090800@gmail.com> jutaro wrote: > I've installed a GUI application based on gtk2hs. > > It frequently crashes with the error: > leksah: error: a C finalizer called back into Haskell. > use Foreign.Concurrent.newForeignPtr for Haskell finalizers. > > This error did never occur with the 6.10 released version. It was verified > that this happens on different machines. I've no idea how to isolate this > bug. This will need to be fixed in gtk2hs. Previously GHC allowed finalizers to call back into Haskell, but this was never officially supported. Now it is officially unsupported, because finalizers created via Foreign.mkForeignPtr are run directly by the garbage collector. See http://hackage.haskell.org/trac/ghc/ticket/1364 Cheers, Simon From marlowsd at gmail.com Thu Mar 19 06:59:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Mar 19 06:47:50 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 In-Reply-To: <200903181536.36337.naur@post11.tele.dk> References: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> <2B2A5BDC-B4A7-4E2D-A42D-B190A0A9FDA2@googlemail.com> <200903181536.36337.naur@post11.tele.dk> Message-ID: <49C225AA.70804@gmail.com> Thorkil Naur wrote: > Hello Thomas, > > On Wednesday 18 March 2009 15:03, Thomas Schilling wrote: >> There should be a file called testlog somewhere, either at the >> toplevel or within the tests directory. Could you search for >> "apirecomp001" and send me the test output from running that test. I >> can't reproduce this failure when running it manually even though I'm >> on OS X, too. > > Several of the buildbot slaves fail the apirecomp001(normal) test as well. For > eaxmple, here is the output from > > http://darcs.haskell.org/buildbot/all/builders/tnaur%20x86%20Linux%20head/builds/333/steps/runtestsuite/logs/unexpected > > for that test: > > =====> apirecomp001(normal) > cd ./ghc-api/apirecomp001 && $MAKE -s --no-print-directory apirecomp001 > apirecomp001.run.stdout 2>apirecomp001.run.stderr > Wrong exit code (expected 0 , actual 2 ) > Stdout: > > Stderr: > make[1]: myghc: Command not found > make[1]: *** [apirecomp001] Error 127 I suspect Thomas has "." in his PATH. Naughty :-) This fixes it: - @myghc $(TOP)/.. + @./myghc $(TOP)/.. I'll validate and push. Cheers, Simon From igloo at earth.li Thu Mar 19 10:31:27 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 19 10:19:17 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <49C21F05.4040409@centrum.cz> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE293D.9020709@centrum.cz> <20090319003740.GA1157@matrix.chaos.earth.li> <49C21F05.4040409@centrum.cz> Message-ID: <20090319143127.GA13371@matrix.chaos.earth.li> On Thu, Mar 19, 2009 at 11:31:33AM +0100, Karel Gardas wrote: > > /var/tmp/ghc-6.10.1.20090314/utils/installPackage/install-inplace/bin/installPackage > install > '/var/tmp/ghc-6.10.1.20090314/utils/ghc-pkg/install-inplace/bin/ghc-pkg' > '/var/tmp/ghc-6.10.1.20090314/inplace-datadir/package.conf' '' \ > '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \ > '/var/tmp/ghc-6.10.1.20090314/utils/haddock/install-inplace' \ > '$prefix/bin' \ > '$prefix/lib' \ > '$prefix/libexec' \ > '$prefix/dynlib' \ > '$prefix/share' \ > '$prefix/doc' \ > '$prefix/html' \ > '$prefix/haddock' \ > --distpref dist-install \ > --enable-shell-wrappers > > The message `internal error: error_message(28)' looks suspiciously, is > there any Sun ar invoked behind the scene? Or isn't this message from > the AR but coming from something else? Try running the above command but with -v2 or -v3 appended, and it should show you what is being run. Looks like strip is probably the culprit. Thanks Ian From colin at colina.demon.co.uk Thu Mar 19 10:53:23 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Thu Mar 19 10:41:18 2009 Subject: Adding DPH to HEAD Message-ID: I tried following the advice on the DPH wiki: ./sync-all --dph get This wouldn't run because of permissions, so I tried putting sh in front of the command. This produced a lot of error messages: ./sync-all: line 3: use: command not found ./sync-all: line 4: use: command not found ./sync-all: line 8: git: command not found ./sync-all: line 8: my: command not found ./sync-all: line 8: chomp: command not found ./sync-all: line 9: git: command not found ./sync-all: line 9: my: command not found ./sync-all: line 9: chomp: command not found ./sync-all: line 10: git: command not found ./sync-all: line 10: my: command not found ./sync-all: line 10: chomp: command not found ./sync-all: line 12: my: command not found ./sync-all: line 13: my: command not found ./sync-all: line 15: syntax error near unexpected token `{' ./sync-all: line 15: `if ($defaultrepo =~ /^...*:/) {' Following a suggestion from Simon Marlow, I instead tried: ./darcs-all --dph get which was more successful. Does the wiki page need updating? But when I then typed make I got: --constraint="Cabal == 1.7.0" Configuring installPackage-1.0... cabal-bin: The following installed packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used. package Cabal-1.7.0 is broken due to missing package array-0.2.0.0, containers-0.2.0.0, process-1.0.1.0 make[2]: *** [with-bootstrapping-compiler] Error 1 make[2]: Leaving directory `/home/colin/ghc/utils/installPackage' make[1]: *** [with-bootstrapping-compiler.installPackage] Error 2 make[1]: Leaving directory `/home/colin/ghc/utils' make: *** [stage1] Error 2 What do I do in such circumstances? I tried a cabal install Cabal --rebuild which seemed to work OK, but when i type make again i get the same error as before. -- Colin Adams Preston Lancashire From igloo at earth.li Thu Mar 19 13:03:26 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 19 12:51:18 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <200903181235.01963.naur@post11.tele.dk> References: <20090315155142.GA18000@matrix.chaos.earth.li> <200903181235.01963.naur@post11.tele.dk> Message-ID: <20090319170326.GB13371@matrix.chaos.earth.li> On Wed, Mar 18, 2009 at 12:35:01PM +0100, Thorkil Naur wrote: > > I have tried the Intel Mac installer and the source package on both FreeBSD > and PPC Mac OS X. Some comments follow Thanks! > 1. An important property of such installers is that you are told, right from > the start, that all the information you are presented with during the > installation process can be accessed at any time, after completion of the > installation, and you are told how. In case of GHC, something like a > reference to a suitable spot, given as part of the output from ghc --help. I > don't see any trace of such a facility on the introduction screen. (I know > that other installers don't do this either, which is part of the reason why I > try to avoid them.) I didn't follow that; can you say exactly what text you want where, please? > 2. The introduction screen says "This package must be installed on the system > volume" which seems to imply that there is some kind of choice involved at a > later stage. But I don't recall having to perform any choice that related to > this. So perhaps this should be "This package will be installed on the system > volume" instead. Good point, done. > 3. I can copy and paste the text of the introduction screen, excellent. I > cannot copy and paste the header. I don't think there's anything we can do about this. > 4. On the License screen, GMP is denoted "GNU MP Bignum Library" in two > places. I suggest using "GNU Multiple Precision Arithmetic Library" (from > http://gmplib.org/) instead. The title of that page is "The GNU MP Bignum Library", and the docs seem to be mostly consistent in calling it the "GNU MP Library", so I'm going to leave it as it is unless there's consensus for a change. > 5. On the License screen, replace "licence" by "license", twice. Thanks, changed to make it consistent. > 6. The License screen explains "that by default the GMP will be statically > linked into any binary produced by GHC. Software with a non-GPL compatible > licence [sic] will have to ensure that the conditions of the LGPL are met; > for example, by forcing GMP to link dynamically instead." Some details or a > reference to an explanation of how to do this would be nice. I don't think we want details in the installer, but we should have something in the docs somewhere. > Also, shouldn't "non-GPL compatible" be plain "non-GPL"? No, I believe (IANAL etc) any license that provides the appropriate freedoms is OK. > 7. I may very well be wrong, but as far as I have been able to tell, the ghc > executable itself that is distributed > (/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc) > contains GMP, statically linked. For example: > > > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 > thorkilnaur$ DYLD_PRINT_LIBRARIES=YES /usr/bin/ghc --version > > dyld: loaded: /bin/sh > > dyld: loaded: /usr/lib/libncurses.5.4.dylib > > dyld: loaded: /usr/lib/libiconv.2.dylib > > dyld: loaded: /usr/lib/libSystem.B.dylib > > dyld: loaded: /usr/lib/libgcc_s.1.dylib > > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > > dyld: > loaded: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1.20090314/ghc > > dyld: loaded: /usr/lib/libedit.2.dylib > > dyld: loaded: /usr/lib/libncurses.5.4.dylib > > dyld: loaded: /usr/lib/libSystem.B.dylib > > dyld: loaded: /usr/lib/libgcc_s.1.dylib > > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > > The Glorious Glasgow Haskell Compilation System, version 6.10.1.20090314 > > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 > thorkilnaur$ > > where I fail to observe anything that seems to relate to GMP. This is in > contrast to the corresponding information for an earlier GHC installation > > > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 > thorkilnaur$ DYLD_PRINT_LIBRARIES=YES ghc --version > > dyld: loaded: /bin/sh > > dyld: loaded: /usr/lib/libncurses.5.4.dylib > > dyld: loaded: /usr/lib/libiconv.2.dylib > > dyld: loaded: /usr/lib/libSystem.B.dylib > > dyld: loaded: /usr/lib/libgcc_s.1.dylib > > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > > dyld: > loaded: /Users/thorkilnaur/tn/install/ghc-6.8.3/lib/ghc-6.8.3/ghc-6.8.3 > > dyld: loaded: /opt/local/lib/libreadline.5.2.dylib > > dyld: loaded: /opt/local/lib/libncurses.5.dylib > > dyld: loaded: /usr/lib/libSystem.B.dylib > > dyld: loaded: /opt/local/lib/libgmp.3.dylib > > dyld: loaded: /usr/lib/libgcc_s.1.dylib > > dyld: loaded: /usr/lib/system/libmathCommon.A.dylib > > The Glorious Glasgow Haskell Compilation System, version 6.8.3 > > thorkil-naurs-intel-mac-mini:~/tn/test/GHC/release/GHC-6.10.2-rc1 > thorkilnaur$ > > where one observes the presence of "dyld: > loaded: /opt/local/lib/libgmp.3.dylib" that loads the separately installed > dynamic GMP library. Hmm, I'm note sure why that changed. Manuel, do you know? > 9. I cannot copy and paste the text or the header of the Installation Type > screen, the one that says "This will take 448 MB of space on your computer. > Click Install to perform a standard installation of this software for all > users of this computer." That looks like it's baked into the installer generator, i.e. i don't think we can change it. > 10. On the Summary screen, I am told to find additional documentation at > "/usr/share/doc/ghc/index.html". Should that, perhaps, be > "file:///usr/share/doc/ghc/index.html" or something else, that more directly > indicates how to access this documentation? And also mention the use of a > browser? I think /usr/share/doc/ghc/index.html will work in any web browser. I've tweaked the text a bit. > 12. What happens if I have a GHC installed already? To check this, I tried > running the installer twice, without uninstalling in between. I didn't notice > any difference between the first and second install. So I guess that the > first installation was simply being overwritten. > > I realise that the /Library/Framework conventions allow multiple versions of > the same thing to be installed. But the way the GHC package is supposed to be > accessed is via symbolic links in /usr/bin (and elsewhere?) and these links > are surely being overwritten. If there is a mechanism for changing between > versions, I haven't noticed it. I don't know enough about the OS X installers to know if we can do better on this. I'll take a look at your testsuite failures separately. Thanks Ian From igloo at earth.li Thu Mar 19 13:14:54 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 19 13:02:46 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <49BE6979.9030304@dfki.de> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> Message-ID: <20090319171454.GC13371@matrix.chaos.earth.li> On Mon, Mar 16, 2009 at 04:00:09PM +0100, Christian Maeder wrote: > > Under Solaris grep does not understand "-q" in configure: > > checkMake380() { > if $1 --version 2>&1 | head -1 | grep -q 'GNU Make 3\.80' > > it fails with: > > grep: illegal option -- q > Usage: grep -hblcnsviw pattern file . . . > grep: illegal option -- q > Usage: grep -hblcnsviw pattern file . . . OK, I'll just redirect stdout to /dev/null then. Presumably these print 0 and 1 respectively? echo foo | grep foo > /dev/null; echo $? echo foo | grep bar > /dev/null; echo $? Thanks Ian From igloo at earth.li Thu Mar 19 13:20:29 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 19 13:08:20 2009 Subject: Under Solaris: GHC 6.10.2 Release Candidate 1 In-Reply-To: <49BF8EBB.30607@centrum.cz> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> <49BF76D1.4060508@dfki.de> <49BF8EBB.30607@centrum.cz> Message-ID: <20090319172029.GD13371@matrix.chaos.earth.li> On Tue, Mar 17, 2009 at 12:51:23PM +0100, Karel Gardas wrote: > Christian Maeder wrote: > > Testsuite results are bad for ghc-6.10.1.20090314, see > > http://hackage.haskell.org/trac/ghc/ticket/3106 > > Patch for the cygpath not found issue is attached to the ticket. Please > (Windows/Cygwin/Mingw users especially) test it. Thanks; I'll apply one of the fixes and test on Windows platforms. Thanks Ian From Christian.Maeder at dfki.de Thu Mar 19 13:51:43 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Mar 19 13:39:33 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090319171454.GC13371@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> <49BE6979.9030304@dfki.de> <20090319171454.GC13371@matrix.chaos.earth.li> Message-ID: <49C2862F.10008@dfki.de> Ian Lynagh wrote: > On Mon, Mar 16, 2009 at 04:00:09PM +0100, Christian Maeder wrote: >> Under Solaris grep does not understand "-q" in configure: >> >> checkMake380() { >> if $1 --version 2>&1 | head -1 | grep -q 'GNU Make 3\.80' >> >> it fails with: >> >> grep: illegal option -- q >> Usage: grep -hblcnsviw pattern file . . . >> grep: illegal option -- q >> Usage: grep -hblcnsviw pattern file . . . > > OK, I'll just redirect stdout to /dev/null then. > > Presumably these print 0 and 1 respectively? > > echo foo | grep foo > /dev/null; echo $? > echo foo | grep bar > /dev/null; echo $? Yes, Christian -bash-3.00$ echo foo | grep foo > /dev/null; echo $? 0 -bash-3.00$ echo foo | grep bar > /dev/null; echo $? 1 From igloo at earth.li Thu Mar 19 14:57:34 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 19 14:45:24 2009 Subject: Adding DPH to HEAD In-Reply-To: References: Message-ID: <20090319185734.GA18255@matrix.chaos.earth.li> Hi Colin, On Thu, Mar 19, 2009 at 02:53:23PM +0000, Colin Paul Adams wrote: > I tried following the advice on the DPH wiki: > > ./sync-all --dph get I would recommend starting with a clean tree by untarring http://darcs.haskell.org/ghc-HEAD-2009-01-09-ghc-corelibs-testsuite.tar.bz2 and then doing ./darcs-all pull -a ./darcs-all --dph get For now, avoid any instructions that tell you to use git or sync-all. Thanks Ian From martin.sulzmann.haskell at googlemail.com Thu Mar 19 15:45:41 2009 From: martin.sulzmann.haskell at googlemail.com (Martin Sulzmann) Date: Thu Mar 19 15:33:31 2009 Subject: [Haskell] Re: indirectly recursive dictionaries In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C334CBB6055C@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090318032653.50C67AF97@Adric.metnet.fnmoc.navy.mil> <638ABD0A29C8884A91BC5FB5C349B1C334CBB6055C@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4bb51c60903191245r59777dfbke52ccfe2078c96f7@mail.gmail.com> On Wed, Mar 18, 2009 at 9:45 AM, Simon Peyton-Jones wrote: > [Redirecting to GHC users.] > > | Tom Schrijvers wrote: > | > The cyclic dictionaries approach is a bit fragile. The problem appears > to > | > be here that GHC alternates exhaustive phases of constraint reduction > and > | > functional dependency improvement. The problem is that in your example > you > | > need both for detecting a cycle. > > The whole thing relies on "spotting a loop", and that's inherently a bit > fragile. I don't know of any formal work on the subject, although I bet > there is some. Satish R. Thatte: Semantics of Type Classes Revisited http://portal.acm.org/citation.cfm?id=182459 The first reference I'm aware of which discusses co-induction in the type class context. There are no recursive dictionaries because Thatte's type class semantics uses run-time type passing (plus method lookup) instead of dictionary-passing. Recursive dictionaries are formalized here Martin Sulzmann: Extracting programs from type class proofs http://portal.acm.org/citation.cfm?id=1140348 There's no work I know of which discusses type inference in the presence of co-inductive type classes (and its subtle consequences as pointed out by Tom's earlier email). Chameleon has supported them using the strategy to apply first improvement before considering co-induction. -Martin > > GHC's current algorithm does not run functional dependencies sufficiently > aggressively, because it treats fundeps a different kind of thing to class > constraints. Our new solver, long promised but still in the works, fully > integrates type classes with type equalities (fundeps, type functions etc), > and so should do a better job here. Roughly speaking, the idea is to > combine our ICFP'08 paper [1] with a type-class solver. Since writing the > ICFP'08 paper we have found some very useful simplifications; and we also > have a new plan for the solving strategy "OutsideIn" [2]. > > That said, solving recursive problems is not our primary focus right now -- > getting it working is -- so I can't promise that it'll do a better job, but > I think it will. > > | It seems we can convince GHC to do constraint reduction and > | improvement in the order we desire. The key is to use the > | continuation-passing style -- which forces things to happen in the > | right order, both at the run-time and at the compile time. > > Oleg you are a master at persuading GHC's somewhat ad-hoc implementation to > dance to your tune. But it'd be better just to make the implementation more > complete in the solutions it finds. That's what we are working on now. > > Simon > > [1] http://research.microsoft.com/~simonpj/papers/assoc-types/index.htm > [2] http://research.microsoft.com/~simonpj/papers/gadt > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090319/1f29e4ba/attachment.htm From jules at jellybean.co.uk Thu Mar 19 16:25:03 2009 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Mar 19 16:12:56 2009 Subject: Another victim of the state hack Message-ID: <49C2AA1F.1060603@jellybean.co.uk> I have the impression that it's useful to you to see how often the state hack trips people up, so I've added some more comments to http://hackage.haskell.org/trac/ghc/ticket/2284 ...about how it bit me. This is a real headache. To be frank, controlling lazy evaluation and sharing to get the right complexity for your code can be hard enough at the best of times, without the compiler sometimes ignoring the sharing you try to ask for... From jnf at arcor.de Thu Mar 19 16:43:26 2009 From: jnf at arcor.de (jutaro) Date: Thu Mar 19 16:31:15 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <49C223AB.2090800@gmail.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> <49C223AB.2090800@gmail.com> Message-ID: <22608413.post@talk.nabble.com> Hello Simon, I've put a request about the issue on the gtk2hs users mailing list: > I've tried a gtk2hs app on ghc 6.10.2 release candidate. > It crashes frequently and Simon (as you can read down here) assumes it > is gtk2hs problem. > My question is: > Is this problem known to gtk2hs developers? > Is it really a gtk2hs problem? > How difficult is it to fix the problem? > When will we have a patch to use gtk2hs with 6.10.2, > is it already in the repo? However, I'm a little surprised that a little version upgrade from 6.10.1 to 6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps are affected because of this change? What's about wxhaskell e.g.? Well, maybe we have only few Haskell applications around, but usually I wouldn't expect such a dramatic effect from such a moderate upgrade. Is this fix so important to introduce it now? What does it help when it was never officially supported if it causes such troubles? J?rgen Simon Marlow-7 wrote: > > jutaro wrote: >> I've installed a GUI application based on gtk2hs. >> >> It frequently crashes with the error: >> leksah: error: a C finalizer called back into Haskell. >> use Foreign.Concurrent.newForeignPtr for Haskell finalizers. >> >> This error did never occur with the 6.10 released version. It was >> verified >> that this happens on different machines. I've no idea how to isolate this >> bug. > > This will need to be fixed in gtk2hs. Previously GHC allowed finalizers > to > call back into Haskell, but this was never officially supported. Now it > is > officially unsupported, because finalizers created via > Foreign.mkForeignPtr > are run directly by the garbage collector. > > See > > http://hackage.haskell.org/trac/ghc/ticket/1364 > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From colin at colina.demon.co.uk Thu Mar 19 16:55:08 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Thu Mar 19 16:42:59 2009 Subject: Adding DPH to HEAD In-Reply-To: <20090319185734.GA18255@matrix.chaos.earth.li> (Ian Lynagh's message of "Thu\, 19 Mar 2009 18\:57\:34 +0000") References: <20090319185734.GA18255@matrix.chaos.earth.li> Message-ID: >>>>> "Ian" == Ian Lynagh writes: Ian> Hi Colin, Ian> On Thu, Mar 19, 2009 at 02:53:23PM +0000, Colin Paul Adams wrote: >> I tried following the advice on the DPH wiki: >> >> ./sync-all --dph get Ian> I would recommend starting with a clean tree by untarring Ian> http://darcs.haskell.org/ghc-HEAD-2009-01-09-ghc-corelibs-testsuite.tar.bz2 Ian> and then doing ./darcs-all pull -a ./darcs-all --dph get Ian> For now, avoid any instructions that tell you to use git or Ian> sync-all. OK. That seems to work. Everything up to make install went fine. After the re-install, I need to re-install various packages using Cabal in order to compile my program afresh. So I then went back to the ghc directory, and typed make again - just to see. I get this: Configuring installPackage-1.0... /home/colin/ghc/libraries/cabal-bin ghc /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 build --distpref dist-inplace --ghc-option=-H32m --ghc-option=-O --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... [1 of 1] Compiling Main ( installPackage.hs, dist-inplace/build/installPackage/installPackage-tmp/Main.o ) installPackage.hs:4:0: Bad interface file: /home/colin/ghc/libraries/Cabal/dist-bootstrapping/build/Distribution/PackageDescription.hi mismatched interface file versions (wanted "61120090319", got "61120090317") make[2]: *** [with-bootstrapping-compiler] Error 1 make[2]: Leaving directory `/home/colin/ghc/utils/installPackage' make[1]: *** [with-bootstrapping-compiler.installPackage] Error 2 make[1]: Leaving directory `/home/colin/ghc/utils' make: *** [stage1] Error 2 I have no idea what is going on. -- Colin Adams Preston Lancashire From dons at galois.com Thu Mar 19 19:34:09 2009 From: dons at galois.com (Don Stewart) Date: Thu Mar 19 19:22:58 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <22608413.post@talk.nabble.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> <49C223AB.2090800@gmail.com> <22608413.post@talk.nabble.com> Message-ID: <20090319233409.GC12301@whirlpool.galois.com> We must have the gtk2hs team invovled in this discussion. They were using an undocumented feature. It may be trivial to fix. --Don jnf: > > Hello Simon, > I've put a request about the issue on the gtk2hs users mailing list: > > > I've tried a gtk2hs app on ghc 6.10.2 release candidate. > > It crashes frequently and Simon (as you can read down here) assumes it > > is gtk2hs problem. > > My question is: > > Is this problem known to gtk2hs developers? > > Is it really a gtk2hs problem? > > How difficult is it to fix the problem? > > When will we have a patch to use gtk2hs with 6.10.2, > > is it already in the repo? > > However, I'm a little surprised that a little version upgrade from 6.10.1 to > 6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps > are affected because of this change? What's about wxhaskell e.g.? Well, > maybe we have only few Haskell applications around, but usually I > wouldn't expect such a dramatic effect from such a moderate upgrade. Is this > fix so important to introduce it now? What does it help when it was never > officially supported if it causes such troubles? > > J?rgen > > > > Simon Marlow-7 wrote: > > > > jutaro wrote: > >> I've installed a GUI application based on gtk2hs. > >> > >> It frequently crashes with the error: > >> leksah: error: a C finalizer called back into Haskell. > >> use Foreign.Concurrent.newForeignPtr for Haskell finalizers. > >> > >> This error did never occur with the 6.10 released version. It was > >> verified > >> that this happens on different machines. I've no idea how to isolate this > >> bug. > > > > This will need to be fixed in gtk2hs. Previously GHC allowed finalizers > > to > > call back into Haskell, but this was never officially supported. Now it > > is > > officially unsupported, because finalizers created via > > Foreign.mkForeignPtr > > are run directly by the garbage collector. > > > > See > > > > http://hackage.haskell.org/trac/ghc/ticket/1364 > > > > Cheers, > > Simon > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > -- > View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html > Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From duncan.coutts at worc.ox.ac.uk Thu Mar 19 20:06:54 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 19 19:54:42 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090319233409.GC12301@whirlpool.galois.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> <49C223AB.2090800@gmail.com> <22608413.post@talk.nabble.com> <20090319233409.GC12301@whirlpool.galois.com> Message-ID: <1237507614.22581.65.camel@localhost> On Thu, 2009-03-19 at 16:34 -0700, Don Stewart wrote: > We must have the gtk2hs team invovled in this discussion. They were > using an undocumented feature. It may be trivial to fix. > > > This will need to be fixed in gtk2hs. Previously GHC allowed finalizers > > > to call back into Haskell, but this was never officially supported. Now it > > > is officially unsupported, because finalizers created via > > > Foreign.mkForeignPtr are run directly by the garbage collector. I had a quick look but so far I cannot see where any callback into Haskell is happening. The only interesting case I've found is one finaliser which is implemented in C and uses hs_free_stable_ptr. Duncan From chak at cse.unsw.edu.au Thu Mar 19 20:10:29 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Mar 19 19:58:21 2009 Subject: Adding DPH to HEAD In-Reply-To: References: Message-ID: <69985F39-E75C-44D8-B243-6008CF7A3DDC@cse.unsw.edu.au> Colin Paul Adams: > I tried following the advice on the DPH wiki: > > ./sync-all --dph get > > This wouldn't run because of permissions, so I tried putting sh in > front of the command. This produced a lot of error messages: Some guy by the handle of Megacz added this to the page. No idea why. I'll change that. Manuel From jpm at cs.uu.nl Fri Mar 20 04:33:07 2009 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Fri Mar 20 04:21:12 2009 Subject: Problem with a second installed version of the syb package Message-ID: <52f14b210903200133w43152ab0rcf8bd78eb964d111@mail.gmail.com> Hello all, I mentioned this problem before on IRC and remember this might have had something to do with syb having been unversioned in the release of GHC 6.10.1. However, I've tested this under 6.10.2-rc1 and the problem is still there. Concretely, the problem is: I've developed a sucessor package to syb-0.1.0.0. I can install it with runghc Setup.hs install. However, after having installed it I can't use it, getting this error when loading any module that imports Data.Generics: Bad interface file: C:\Program Files (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi Something is amiss; requested module syb:Data.Generics differs from name found in the interface file syb-0.2.0.0:Data.Generics Failed, modules loaded: none. What is the problem here? Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090320/cce4000a/attachment.htm From bulat.ziganshin at gmail.com Fri Mar 20 06:11:53 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Mar 20 06:00:10 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090319233409.GC12301@whirlpool.galois.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> <49C223AB.2090800@gmail.com> <22608413.post@talk.nabble.com> <20090319233409.GC12301@whirlpool.galois.com> Message-ID: <409849831.20090320131153@gmail.com> Hello Don, Friday, March 20, 2009, 2:34:09 AM, you wrote: the question is wider - how many other programs already used this behavior? it may be asked on main haskell list. what is the cost of reverting it back for 6.10.*? > We must have the gtk2hs team invovled in this discussion. They were > using an undocumented feature. It may be trivial to fix. > --Don > jnf: >> >> Hello Simon, >> I've put a request about the issue on the gtk2hs users mailing list: >> >> > I've tried a gtk2hs app on ghc 6.10.2 release candidate. >> > It crashes frequently and Simon (as you can read down here) assumes it >> > is gtk2hs problem. >> > My question is: >> > Is this problem known to gtk2hs developers? >> > Is it really a gtk2hs problem? >> > How difficult is it to fix the problem? >> > When will we have a patch to use gtk2hs with 6.10.2, >> > is it already in the repo? >> >> However, I'm a little surprised that a little version upgrade from 6.10.1 to >> 6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps >> are affected because of this change? What's about wxhaskell e.g.? Well, >> maybe we have only few Haskell applications around, but usually I >> wouldn't expect such a dramatic effect from such a moderate upgrade. Is this >> fix so important to introduce it now? What does it help when it was never >> officially supported if it causes such troubles? >> >> J?rgen >> >> >> >> Simon Marlow-7 wrote: >> > >> > jutaro wrote: >> >> I've installed a GUI application based on gtk2hs. >> >> >> >> It frequently crashes with the error: >> >> leksah: error: a C finalizer called back into Haskell. >> >> use Foreign.Concurrent.newForeignPtr for Haskell finalizers. >> >> >> >> This error did never occur with the 6.10 released version. It was >> >> verified >> >> that this happens on different machines. I've no idea how to isolate this >> >> bug. >> > >> > This will need to be fixed in gtk2hs. Previously GHC allowed finalizers >> > to >> > call back into Haskell, but this was never officially supported. Now it >> > is >> > officially unsupported, because finalizers created via >> > Foreign.mkForeignPtr >> > are run directly by the garbage collector. >> > >> > See >> > >> > http://hackage.haskell.org/trac/ghc/ticket/1364 >> > >> > Cheers, >> > Simon >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users@haskell.org >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > >> > >> >> -- >> View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html >> Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Fri Mar 20 18:32:54 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Mar 20 18:20:41 2009 Subject: Another victim of the state hack In-Reply-To: <49C2AA1F.1060603@jellybean.co.uk> References: <49C2AA1F.1060603@jellybean.co.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C334CBC18F80@EA-EXMSG-C334.europe.corp.microsoft.com> | This is a real headache. To be frank, controlling lazy evaluation and | sharing to get the right complexity for your code can be hard enough at | the best of times, without the compiler sometimes ignoring the sharing | you try to ask for... Yes, I agree. The trade off is that without the hack all programs go a bit slower, and I don't know how to fix that. I have not measured this effect recently; maybe it's small. Thanks for updating the ticket with more info; v helpful S From igloo at earth.li Fri Mar 20 19:21:13 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Mar 20 19:08:59 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <22608413.post@talk.nabble.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> <49C223AB.2090800@gmail.com> <22608413.post@talk.nabble.com> Message-ID: <20090320232113.GA8687@matrix.chaos.earth.li> On Thu, Mar 19, 2009 at 01:43:26PM -0700, jutaro wrote: > > Is this > fix so important to introduce it now? What does it help when it was never > officially supported if it causes such troubles? The reason it's now not allowed is that 6.10.2 provides guarantees about running C finalizers that 6.10.1 did not. See http://hackage.haskell.org/trac/ghc/ticket/1364 for more details. Thanks Ian From igloo at earth.li Fri Mar 20 19:39:30 2009 From: igloo at earth.li (Ian Lynagh) Date: Fri Mar 20 19:27:15 2009 Subject: Problem with a second installed version of the syb package In-Reply-To: <52f14b210903200133w43152ab0rcf8bd78eb964d111@mail.gmail.com> References: <52f14b210903200133w43152ab0rcf8bd78eb964d111@mail.gmail.com> Message-ID: <20090320233930.GA8825@matrix.chaos.earth.li> On Fri, Mar 20, 2009 at 09:33:07AM +0100, Jos? Pedro Magalh?es wrote: > > Bad interface file: C:\Program Files > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi > Something is amiss; requested module syb:Data.Generics differs from > name found in the interface file syb-0.2.0.0:Data.Generics > Failed, modules loaded: none. > > What is the problem here? What does ghc --show-iface "C:\Program Files (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi" say? Also, if you add -v to the commandline that is going wrong then what does it say that syb is being mapped to? Thanks Ian From naur at post11.tele.dk Sat Mar 21 07:33:38 2009 From: naur at post11.tele.dk (Thorkil Naur) Date: Sat Mar 21 07:24:06 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <20090319170326.GB13371@matrix.chaos.earth.li> References: <20090315155142.GA18000@matrix.chaos.earth.li> <200903181235.01963.naur@post11.tele.dk> <20090319170326.GB13371@matrix.chaos.earth.li> Message-ID: <200903211233.40026.naur@post11.tele.dk> Hello, On Thursday 19 March 2009 18:03, Ian Lynagh wrote: > On Wed, Mar 18, 2009 at 12:35:01PM +0100, Thorkil Naur wrote: > ... > > 1. An important property of such installers is that you are told, right from > > the start, that all the information you are presented with during the > > installation process can be accessed at any time, after completion of the > > installation, and you are told how. In case of GHC, something like a > > reference to a suitable spot, given as part of the output from ghc --help. I > > don't see any trace of such a facility on the introduction screen. (I know > > that other installers don't do this either, which is part of the reason why I > > try to avoid them.) > > I didn't follow that; can you say exactly what text you want where, > please? The point of this item is to avoid the uneasiness that I often feel when running though such a sequence of screens, that some piece of information that I am given is not available anywhere else and that it is forever gone, once the screen that contains it has been replaced by the next in the sequence. Hence also my interest in being able to copy and paste the contents of these screens. A suggested way to reduce this uneasiness would be: 1a. Add this text to the Introduction screen: "The complete text of the installation session will be available after installation at /usr/share/doc/ghc/INSTALL_SESSION_MACOSX.txt [say]. Invoking the command 'ghc --help' in a Terminal window will mention the location of this file." So, all I have to remember now is 'ghc --help'. 1b. And, of course, now we have to produce this file INSTALL_SESSION_MACOSX.txt, somehow, and include it in the installation. I am not sure what this file should be, but let me say first that I am not thinking of an installation log or something like that, I am thinking of something that can be produced statically, as part of producing the installation package. Ideally, if the package is produced by some tool, it would be possible to extract the contents of various screens in text form and use that. Or perhaps there is some script for generating the installation package that could be used directly or with a few edits. In any case, the file should contain, in text form, whatever text is presented to the user during installation. So a list of header, contents, in the order used during installation. 1c. And 'ghc --help' should be extended to mention the INSTALL_SESSION_MACOSX.txt file. Not necessarily a trivial change, I admit, but I would consider it very useful. > ... Best regards Thorkil From colin at colina.demon.co.uk Sat Mar 21 08:54:24 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sat Mar 21 08:42:09 2009 Subject: Can't find parsec Message-ID: I am trying to incorporate Dana Xu's static contract checking code into ghc 6.11. I've run into a problem that puzzles me. I am getting the following error message: verify/SimplIface.lhs:16:7: Could not find module `Text.ParserCombinators.Parsec.Language': Use -v to see a list of the files searched for. But a quick find command shows that ./utils/ext-core/Language/Core/ParsecParser.hs has this very same import, so I figure it must be usable within the compiler. What do I have to do to get it to find this module? -- Colin Adams Preston Lancashire From dons at galois.com Sat Mar 21 12:51:25 2009 From: dons at galois.com (Don Stewart) Date: Sat Mar 21 12:40:26 2009 Subject: Can't find parsec In-Reply-To: References: Message-ID: <20090321165125.GA20212@whirlpool.galois.com> colin: > I am trying to incorporate Dana Xu's static contract checking code > into ghc 6.11. I've run into a problem that puzzles me. I am getting > the following error message: > > > verify/SimplIface.lhs:16:7: > Could not find module `Text.ParserCombinators.Parsec.Language': > Use -v to see a list of the files searched for. > > > But a quick find command shows that > > ./utils/ext-core/Language/Core/ParsecParser.hs > > has this very same import, so I figure it must be usable within the > compiler. > What do I have to do to get it to find this module? cabal install parsec? From colin at colina.demon.co.uk Sat Mar 21 13:02:07 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sat Mar 21 12:49:56 2009 Subject: Can't find parsec In-Reply-To: <20090321165125.GA20212@whirlpool.galois.com> (Don Stewart's message of "Sat\, 21 Mar 2009 09\:51\:25 -0700") References: <20090321165125.GA20212@whirlpool.galois.com> Message-ID: >>>>> "Don" == Don Stewart writes: Don> colin: >> I am trying to incorporate Dana Xu's static contract checking >> code into ghc 6.11. I've run into a problem that puzzles me. I >> am getting the following error message: >> >> >> verify/SimplIface.lhs:16:7: Could not find module >> `Text.ParserCombinators.Parsec.Language': Use -v to see a list >> of the files searched for. >> >> >> But a quick find command shows that >> >> ./utils/ext-core/Language/Core/ParsecParser.hs >> >> has this very same import, so I figure it must be usable within >> the compiler. What do I have to do to get it to find this >> module? Don> cabal install parsec? Well, I thought it was installed (I already have pasec-3.0.0 installed by cabal for the game I'm writing.). But I see now that if I try it I get parsec 2 installed. However, I still get the same error message. -- Colin Adams Preston Lancashire From marlowsd at gmail.com Sat Mar 21 16:31:25 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Sat Mar 21 16:19:04 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <409849831.20090320131153@gmail.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> <49C223AB.2090800@gmail.com> <22608413.post@talk.nabble.com> <20090319233409.GC12301@whirlpool.galois.com> <409849831.20090320131153@gmail.com> Message-ID: <49C54E9D.9070309@gmail.com> Bulat Ziganshin wrote: > Hello Don, > > Friday, March 20, 2009, 2:34:09 AM, you wrote: > > the question is wider - how many other programs already used this > behavior? it may be asked on main haskell list. what is the cost of > reverting it back for 6.10.*? We could revert it, but lots of people asked for this feature (predictable finalizers), which is why we put it in 6.10.2. The fix is fiarly easy: use Foreign.Concurrent.mkForeignPtr with a foreign import. Cheers, Simon > >> We must have the gtk2hs team invovled in this discussion. They were >> using an undocumented feature. It may be trivial to fix. > >> --Don > >> jnf: >>> Hello Simon, >>> I've put a request about the issue on the gtk2hs users mailing list: >>> >>>> I've tried a gtk2hs app on ghc 6.10.2 release candidate. >>>> It crashes frequently and Simon (as you can read down here) assumes it >>>> is gtk2hs problem. >>>> My question is: >>>> Is this problem known to gtk2hs developers? >>>> Is it really a gtk2hs problem? >>>> How difficult is it to fix the problem? >>>> When will we have a patch to use gtk2hs with 6.10.2, >>>> is it already in the repo? >>> However, I'm a little surprised that a little version upgrade from 6.10.1 to >>> 6.10.2 may break all gui apps based on gtk2hs. May it be that many more apps >>> are affected because of this change? What's about wxhaskell e.g.? Well, >>> maybe we have only few Haskell applications around, but usually I >>> wouldn't expect such a dramatic effect from such a moderate upgrade. Is this >>> fix so important to introduce it now? What does it help when it was never >>> officially supported if it causes such troubles? >>> >>> J?rgen >>> >>> >>> >>> Simon Marlow-7 wrote: >>>> jutaro wrote: >>>>> I've installed a GUI application based on gtk2hs. >>>>> >>>>> It frequently crashes with the error: >>>>> leksah: error: a C finalizer called back into Haskell. >>>>> use Foreign.Concurrent.newForeignPtr for Haskell finalizers. >>>>> >>>>> This error did never occur with the 6.10 released version. It was >>>>> verified >>>>> that this happens on different machines. I've no idea how to isolate this >>>>> bug. >>>> This will need to be fixed in gtk2hs. Previously GHC allowed finalizers >>>> to >>>> call back into Haskell, but this was never officially supported. Now it >>>> is >>>> officially unsupported, because finalizers created via >>>> Foreign.mkForeignPtr >>>> are run directly by the garbage collector. >>>> >>>> See >>>> >>>> http://hackage.haskell.org/trac/ghc/ticket/1364 >>>> >>>> Cheers, >>>> Simon >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users@haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> >>>> >>> -- >>> View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22608413.html >>> Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > From colin at colina.demon.co.uk Sun Mar 22 09:09:23 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Mar 22 08:57:06 2009 Subject: How do I add new dependencies and source files into the build system? Message-ID: I have added a subdirectory named verify to the compiler directory, and made a change to simplCore to call functions from it. I have managed to get it to compile by editing ghc.cabal in the compiler directory (after some problems with cabal which are now sorted). But I think this is not the correct way to do it, as ./configure rebuilds this file, it seems. Where should I be doing this? -- Colin Adams Preston Lancashire From donnie at darthik.com Sun Mar 22 12:24:17 2009 From: donnie at darthik.com (Donnie Jones) Date: Sun Mar 22 12:11:57 2009 Subject: How do I add new dependencies and source files into the build system? In-Reply-To: References: Message-ID: Hello Colin, I believe you should edit compiler/ghc.cabal.in -- I believe this file is the input for cabal and used to create the ghc.cabal which gets re-created at ./configure. Also, you may want to look into Ways (compiler/main/StaticFlags.hs and mk/config.mk.in) if you plan on adding any compile-time (static) flags. Hope that helps. -- Donnie Jones On Sun, Mar 22, 2009 at 8:09 AM, Colin Paul Adams wrote: > I have added a subdirectory named verify to the compiler directory, > and made a change to simplCore to call functions from it. > > I have managed to get it to compile by editing ghc.cabal in the > compiler directory (after some problems with cabal which are now > sorted). But I think this is not the correct way to do it, as > ./configure rebuilds this file, it seems. > > Where should I be doing this? > -- > Colin Adams > Preston Lancashire > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From colin at colina.demon.co.uk Sun Mar 22 12:30:47 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Mar 22 12:18:29 2009 Subject: How do I add new dependencies and source files into the build system? In-Reply-To: (Donnie Jones's message of "Sun\, 22 Mar 2009 11\:24\:17 -0500") References: Message-ID: >>>>> "Donnie" == Donnie Jones writes: Donnie> Hello Colin, I believe you should edit Donnie> compiler/ghc.cabal.in -- I believe this file is the input Donnie> for cabal and used to create the ghc.cabal which gets Donnie> re-created at ./configure. Donnie> Also, you may want to look into Ways Donnie> (compiler/main/StaticFlags.hs and mk/config.mk.in) if you Donnie> plan on adding any compile-time (static) flags. Donnie> Hope that helps. -- Donnie Jones Yes, thanks. -- Colin Adams Preston Lancashire From colin at colina.demon.co.uk Sun Mar 22 13:54:40 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Mar 22 13:42:21 2009 Subject: mkIfThenElse Message-ID: This function has disappeard from CoreUtils in recent release(s). I am portfing some code which uses this function (just once). What should I be looking to use instead? -- Colin Adams Preston Lancashire From batterseapower at hotmail.com Sun Mar 22 14:15:18 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sun Mar 22 14:02:59 2009 Subject: mkIfThenElse In-Reply-To: References: Message-ID: <9d4d38820903221115q817582age94fee3d0f773a27@mail.gmail.com> It moved to MkCore: mkIfThenElse :: CoreExpr -> CoreExpr -> CoreExpr -> CoreExpr mkIfThenElse guard then_expr else_expr -- Not going to be refining, so okay to take the type of the "then" clause = mkWildCase guard boolTy (exprType then_expr) [ (DataAlt falseDataCon, [], else_expr), -- Increasing order of tag! (DataAlt trueDataCon, [], then_expr) ] Cheers, Max 2009/3/22 Colin Paul Adams : > This function has disappeard from CoreUtils in recent release(s). I am > portfing some code which uses this function (just once). What should I > be looking to use instead? > -- > Colin Adams > Preston Lancashire > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From colin at colina.demon.co.uk Sun Mar 22 14:46:22 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Mar 22 14:34:04 2009 Subject: mkIfThenElse In-Reply-To: <9d4d38820903221115q817582age94fee3d0f773a27@mail.gmail.com> (Max Bolingbroke's message of "Sun\, 22 Mar 2009 18\:15\:18 +0000") References: <9d4d38820903221115q817582age94fee3d0f773a27@mail.gmail.com> Message-ID: >>>>> "Max" == Max Bolingbroke writes: Max> It moved to MkCore Thanks. What about mkWildId from Id.lhs? That one seems to have vanished. -- Colin Adams Preston Lancashire From batterseapower at hotmail.com Sun Mar 22 15:19:23 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Sun Mar 22 15:07:04 2009 Subject: mkIfThenElse In-Reply-To: References: <9d4d38820903221115q817582age94fee3d0f773a27@mail.gmail.com> Message-ID: <9d4d38820903221219q8d12b6ej658ffdc0e7f22257@mail.gmail.com> 2009/3/22 Colin Paul Adams : >>>>>> "Max" == Max Bolingbroke writes: > > ? ?Max> It moved to MkCore > > Thanks. > > What about mkWildId from Id.lhs? That one seems to have vanished. Looks that might be the same deal (moved to MkCore), assuming this is what you wanted: -- | Make a /wildcard binder/. This is typically used when you need a binder -- that you expect to use only at a *binding* site. Do not use it at -- occurrence sites because it has a single, fixed unique, and it's very -- easy to get into difficulties with shadowing. That's why it is used so little. mkWildBinder :: Type -> Id mkWildBinder ty = mkSysLocal (fsLit "wild") (mkBuiltinUnique 1) ty Cheers, Max From jtod at dcs.gla.ac.uk Mon Mar 23 05:42:31 2009 From: jtod at dcs.gla.ac.uk (John O'Donnell) Date: Mon Mar 23 05:30:10 2009 Subject: Loading plugin with ghc api Message-ID: <49C75987.9080601@dcs.gla.ac.uk> Hi, I would like to use the API for ghc, so that a running program can load a module (Foo.o) and use a function defined in that module. From the documentation available, it seems like that? possible, but I can?t figure out how to do it. There is an example on the wiki, but the explanation just says the code is equivalent to ghc --make. That example does indeed work, but there is no hint as to whether the running program can then access anything defined in the module it has just loaded. Is there any available documentation on how to load a plugin, or any working example somewhere? Thanks in advance, John O?Donnell From jpm at cs.uu.nl Mon Mar 23 05:53:19 2009 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Mon Mar 23 05:41:14 2009 Subject: Problem with a second installed version of the syb package In-Reply-To: <20090320233930.GA8825@matrix.chaos.earth.li> References: <52f14b210903200133w43152ab0rcf8bd78eb964d111@mail.gmail.com> <20090320233930.GA8825@matrix.chaos.earth.li> Message-ID: <52f14b210903230253p120a50c6v826cc59bcc635363@mail.gmail.com> Hello Ian, 2009/3/21 Ian Lynagh > On Fri, Mar 20, 2009 at 09:33:07AM +0100, Jos? Pedro Magalh?es wrote: > > > > Bad interface file: C:\Program Files > > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi > > Something is amiss; requested module syb:Data.Generics differs > from > > name found in the interface file syb-0.2.0.0:Data.Generics > > Failed, modules loaded: none. > > > > What is the problem here? > > What does > > ghc --show-iface "C:\Program Files > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi" > > say? I'm sorry, I reported the error as ran from ghc-6.10.1. Running it with ghc-6.10.2-rc1 I get the error Bad interface file: C:\Program Files (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi Something is amiss; requested module syb:Data.Generics differs from name found in the interface file syb-0.2.0.0:Data.Generics Failed, modules loaded: none. ghc --show-iface "C:\Program Files (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi" says: Magic: Wanted 129742, got 129742 Version: Wanted [6, 1, 0, 1, 2, 0, 0, 9, 0, 3, 1, 4], got [6, 1, 0, 1, 2, 0, 0, 9, 0, 3, 1, 4] Way: Wanted [], got [] interface syb-0.2.0.0:Data.Generics 610120090314 interface hash: 2f252bc190bffcb63bc93af0a7864f85 ABI hash: a2784ce2c50f029ab89be2567641765b export-list hash: 9f48270b3bb91438449202f71d1f8386 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e where export syb-0.2.0.0:Data.Generics.Aliases Generic Generic'|{Generic' Generic' unG eneric'} GenericB GenericM GenericM'|{GM GenericM' unGM} GenericQ GenericQ'|{GQ GenericQ' unGQ} GenericR GenericT GenericT'|{GT GenericT' unGT} choiceMp choiceQ ext0 ext1M ext1Q ext1R ext1T extB extM extMp extQ extR extT mkM mkMp mkQ mkR mk T orElse recoverMp recoverQ export syb-0.2.0.0:Data.Generics.Schemes everything everywhere everywhere' every whereBut everywhereM gcount gdepth gfindtype glength gnodecount gsize gtypecount listify something somewhere synthesize export syb-0.2.0.0:Data.Generics.Text gread gshow export syb-0.2.0.0:Data.Generics.Twins geq gfoldlAccum gmapAccumM gmapAccumQ gma pAccumQl gmapAccumQr gmapAccumT gzip gzipWithM gzipWithQ gzipWithT export ghc-prim:GHC.Generics :*:|{:*: :*:} :+:{Inl Inr} Unit|{Unit Unit} export base:Data.Data ConIndex Constr ConstrRep|{AlgConstr ConstrRep FloatConstr IntConstr StringConstr} Data{dataCast1 dataCast2 dataTypeOf gfoldl gmapM gmapMo gmapMp gmapQ gmapQi gmapQl gmapQr gmapT gunfold toConstr} DataRep|{AlgRep DataR ep FloatRep IntRep NoRep StringRep} DataType Fixity{Infix Prefix} constrFields c onstrFixity constrIndex constrRep constrType dataTypeConstrs dataTypeName dataTy peRep fromConstr fromConstrB fromConstrM indexConstr isAlgType isNorepType maxCo nstrIndex mkConstr mkDataType mkFloatConstr mkFloatType mkIntConstr mkIntType mk NorepType mkStringConstr mkStringType readConstr repConstr showConstr tyconModul e tyconUQname export base:Data.Typeable TyCon TypeRep Typeable{typeOf} Typeable1{typeOf1} Type able2{typeOf2} Typeable3{typeOf3} Typeable4{typeOf4} Typeable5{typeOf5} Typeable 6{typeOf6} Typeable7{typeOf7} cast funResultTy gcast gcast1 gcast2 mkAppTy mkFun Ty mkTyCon mkTyConApp showsTypeRep splitTyConApp tyConString typeOf1Default type Of2Default typeOf3Default typeOf4Default typeOf5Default typeOf6Default typeOfDef ault typeRepArgs typeRepKey typeRepTyCon module dependencies: Data.Generics.Aliases Data.Generics.Instances Data.Generics.Schemes Data.Generics.Text Data.Generics.Twin s package dependencies: ghc-prim integer base orphans: base:Control.Exception.Base syb-0.2.0.0:Data.Generics.Instances base:Data.Tuple base:GHC.Base base:GHC.Float base:GHC.Num family instance modules: import base:Data.Data 2cfe9f6e828ce97d6906225849a7a8df import base:Data.Typeable 00f181e6f8bb32e13d28aad58cee1bf9 import base:GHC.Base 6bdeebb11d04df398eb46d76fd9fedc8 import base:Prelude eac9ca3c0ae6d00a0fc0f1832a247e5e import Data.Generics.Aliases a418fc77a8afb8f63b1349e7e70aae1f exports: 8a3a8813709e82f89b2cbe434cbbeb32 Generic a3d985935013f874e5dce91cd67fc755 Generic' 88e63b7215ef3e70992766168a404331 GenericB b1b3a4bb9264b0843b0aed33984ed6e2 GenericM f1cb29fbd7771577b3ce27762a0176ad GenericM' 270d4c132681a10609808f680f30d2a1 GenericQ acd36022e368af6f81df3e2c9d0655b3 GenericQ' 4fdb300d3293b22b2d81445caaf7f70b GenericR c34610525f7b7b1c9f9866ea45e5f488 GenericT aeab09799011076dc8f091fc77329bb7 GenericT' dfd635d65ef1b252ebb551bd573e2fa4 choiceMp e2a24be4873fbf0985c117f952222ef6 choiceQ 402677c976faf710fa20d0dbfaed4338 ext0 188b47185552ece2b9563d279b9f6b11 ext1M 55c90f3b7aa3b30a09235074ccdd8474 ext1Q 0fdb24f93014e9134d27059cab8791f5 ext1R a85ebb59fcd8c1a276968370a82d4696 ext1T bab0e7a30776525b1b9e8e170817874d extB 599378e0cc7f6e3e61782e3f5e819f6e extM 709f4b5d8c98e31a40af3a15507871f9 extMp 5e8fcc4141d141bf89ede5f96286514c extQ 09256ec13d553bb7d533db2aba1e6ddb extR e6a8c2d13cf699f254418d213ffb02ce extT 16dd11bc8a533fc6f3ee4edd8da36b56 mkM e011e650bd1a6087396a4dede6e2a1df mkMp dbe80e6608d434ccb554389d5e3f29ad mkQ 0bc35ad32fea2b9bc51816ab146830e1 mkR 3396bcc0b237aa8e56572e4082069b06 mkT aadc01dff67d17c2103458fcf84eae37 orElse e07f75850c897d4eff1b993e172a1b0d recoverMp 4f46329c4393b682ea63d5acc423148d recoverQ d6d52a9b5c344bc937541944805bf93a import Data.Generics.Instances be24e3594312407d61d754a104471f52 exports: f9b081a51f91d5be9de0cd5137909f73 import Data.Generics.Schemes 89cca3ef019bd5311992fc94c8e2d9f2 exports: c5d833b93c8fdd62dea214857de57662 everything 9366be0f56347852103e5d0647869181 everywhere c2db8dcff3ce75dbfc11f2dfb43c448f everywhere' cbb509b400eb9774043849fc7abd24a0 everywhereBut a5a32f5290696d97d277e6cf3ba89839 everywhereM 58ca3d5f8ece2b6dfd11e335bd480b22 gcount 4bae2a419da0c4d1c75ea313041d32e0 gdepth ce875ba06e09ee07306385e44e5a1d3a gfindtype a50b0e886f39e79dcd2ae439db65ee43 glength 1d6577a46d8467ccff4dc9b6ca42ef58 gnodecount 8b7419fbff5b9f4ae16e41e631002a98 gsize cb796acfe38c26e540a43269e45553bf gtypecount 226ca256162d808d3a0162b0542b0cbc listify 66c3a24a9a1ad07ec7b03f094c11c1aa something 043694605a8a297710fd1aa7cbaf481f somewhere 9806fc835d327210ec0bbf64d35714c6 synthesize 9c35f4d2f745cde9e5ef62bae4823d40 import Data.Generics.Text cd89d5c73b61195f20a053ea15752a2e exports: 5f980955eacfea020c74a684c0447584 gread cef65a5c719cdfea5d5c3808be676f26 gshow ecddfe04849b966d1e2dafc28cf28d0c import Data.Generics.Twins 7cf0e8cddb763bac384f96d215a3d86b exports: 673b00515535122807b4b85b42ff3894 geq 0c781de732da371ac3c05f27034fd24a gfoldlAccum 1c69ebb9e30c989ae42a20d0f084cf7e gmapAccumM 244b54d9c627ddc206ccc3c7ef2ec659 gmapAccumQ e17d6c35ee436bd1cc08cd011696d6c6 gmapAccumQl 4bce72827a7e2373c4f09770810e15d7 gmapAccumQr 000342ad0f0fcac3e7618dc77b612a85 gmapAccumT 6070b961c37f7edcae4a5591ea987c15 gzip beb1639480a745f9a5017cfa4564e751 gzipWithM 3255db2551d82167b4bb372e91af5e22 gzipWithQ b459a4f22ca94f1e92f472723edad07e gzipWithT 3f96edf00f37f562a3cff3e737a6c096 vectorised variables: vectorised tycons: vectorised reused tycons: Also, if you add -v to the commandline that is going wrong then what > does it say that syb is being mapped to? To syb-0.2.0.0? Output follows: GHCi, version 6.10.1.20090314: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 6.10.1.20090314, for Haskell 98, stage 2 booted by GHC version 6.10.1 Using package config file: C:\ghc\GHC-61~1.2-R\package.conf hiding package syb-0.1.0.1 to avoid conflict with later version syb-0.2.0.0 hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.1 wired-in package base mapped to base-4.1.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.2.0.0 wired-in package template-haskell mapped to template-haskell-2.3.0.1 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. *** Chasing dependencies: Chasing modules from: Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Ready for upsweep [] Upsweep completely successful. *** Deleting temp files: Deleting: *** Chasing dependencies: Chasing modules from: *test.hs Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Thu Feb 5 08:34:16 W. Europe Standard Time 2009 ms_mod = main:Test, ms_imps = [Data.Generics] ms_srcimps = [] }] compile: input file test.hs *** Checking old interface for main:Test: [1 of 1] Compiling Test ( test.hs, interpreted ) *** Parser: *** Renamer/typechecker: test.hs:3:0: Bad interface file: C:\Program Files (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi Something is amiss; requested module syb:Data.Generics differs from name found in the interface file syb-0.2.0.0:Data.Generics *** Deleting temp files: Deleting: Upsweep partially successful. *** Deleting temp files: Deleting: Failed, modules loaded: none. Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090323/26518c09/attachment-0001.htm From marlowsd at gmail.com Mon Mar 23 08:27:41 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Mar 23 08:15:26 2009 Subject: Loading plugin with ghc api In-Reply-To: <49C75987.9080601@dcs.gla.ac.uk> References: <49C75987.9080601@dcs.gla.ac.uk> Message-ID: <49C7803D.2080003@gmail.com> John O'Donnell wrote: > Hi, > > I would like to use the API for ghc, so that a running program can load > a module (Foo.o) and use a function defined in that module. From the > documentation available, it seems like that? possible, but I can?t > figure out how to do it. There is an example on the wiki, but the > explanation just says the code is equivalent to ghc --make. That example > does indeed work, but there is no hint as to whether the running program > can then access anything defined in the module it has just loaded. > > Is there any available documentation on how to load a plugin, or any > working example somewhere? Hi John, Once you have your module loaded, you can call dynCompileExpr :: GhcMonad m => String -> m Dynamic to compile an arbitrary expression, yielding a Dynamic value that you can cast to the appropriate type. Cheers, Simon From ml at isaac.cedarswampstudios.org Mon Mar 23 10:56:40 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Mon Mar 23 10:44:34 2009 Subject: Loading plugin with ghc api In-Reply-To: <49C75987.9080601@dcs.gla.ac.uk> References: <49C75987.9080601@dcs.gla.ac.uk> Message-ID: <200903231056.40712.ml@isaac.cedarswampstudios.org> John O'Donnell wrote: > That example > does indeed work, but there is no hint as to whether the running program > can then access anything defined in the module it has just loaded. I think the running program can only access things *exported* from the module (other functions in that module might even have been optimized away!).... Is it okay to require those plugin-modules to export everything you're going to use from them? -Isaac From claus.reinke at talk21.com Mon Mar 23 19:16:42 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Mar 23 19:04:24 2009 Subject: compilation of pattern-matching? Message-ID: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> I just noticed that GHC (6.11.20090320) seems to compile both f (a:b:c) = f (a:[]) = f [] = and f [] = f (a:[]) = f (a:b:c) = to something like (looking at Core, but writing source) f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}} That doesn't seem right to me: if I try to give the patterns in the order from frequent to rare, in order to reduce jumps, I don't expect GHC to rearrange things. What is the rationale for this? And where can I read about GHC's pattern match compilation approach in general? Claus From lennart at augustsson.net Mon Mar 23 19:37:12 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Mar 23 19:24:49 2009 Subject: compilation of pattern-matching? In-Reply-To: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> Message-ID: How could you match the first case with less than two case constructs? There are two (:) to check for, so I'm not sure what you are complaining about. -- Lennart On Tue, Mar 24, 2009 at 12:16 AM, Claus Reinke wrote: > I just noticed that GHC (6.11.20090320) seems to compile both > > f (a:b:c) = > f (a:[]) = f [] = > and > f [] = f (a:[]) = f (a:b:c) = > > to something like (looking at Core, but writing source) > > f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}} > > That doesn't seem right to me: if I try to give the patterns in > the order from frequent to rare, in order to reduce jumps, I > don't expect GHC to rearrange things. What is the rationale > for this? And where can I read about GHC's pattern match > compilation approach in general? > > Claus > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From claus.reinke at talk21.com Mon Mar 23 19:46:27 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Mar 23 19:34:09 2009 Subject: compilation of pattern-matching? References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> Message-ID: > How could you match the first case with less than two case constructs? > There are two (:) to check for, so I'm not sure what you are complaining about. > -- Lennart The number of case constructs is needed, and since case in Core also specifies strict contexts, perhaps there would be no difference, which is why I'm asking about the rationale/documentation. My idea was that case branches correspond to conditional jumps (though the exact correspondence and optimization has been the subject of countless papers). If I loop through a very long list, most of the time the test for (:) will succeed, requiring no jump, while the test for [] will fail, requiring a jump to the alternative branch. So, if GHC's pattern-match compilation is naive, the reordering will introduce 2 jumps into the common case of the loop where none would be needed, right? Claus > On Tue, Mar 24, 2009 at 12:16 AM, Claus Reinke wrote: >> I just noticed that GHC (6.11.20090320) seems to compile both >> >> f (a:b:c) = >> f (a:[]) = f [] = >> and >> f [] = f (a:[]) = f (a:b:c) = >> >> to something like (looking at Core, but writing source) >> >> f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}} >> >> That doesn't seem right to me: if I try to give the patterns in >> the order from frequent to rare, in order to reduce jumps, I >> don't expect GHC to rearrange things. What is the rationale >> for this? And where can I read about GHC's pattern match >> compilation approach in general? >> >> Claus >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> From twhitehead at gmail.com Mon Mar 23 23:42:21 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Mon Mar 23 23:30:07 2009 Subject: compilation of pattern-matching? In-Reply-To: References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> Message-ID: <200903232342.28864.twhitehead@gmail.com> On March 23, 2009 19:46:27 Claus Reinke wrote: > My idea was that case branches correspond to conditional jumps > (though the exact correspondence and optimization has been the > subject of countless papers). If I loop through a very long list, > most of the time the test for (:) will succeed, requiring no jump, > while the test for [] will fail, requiring a jump to the alternative > branch. So, if GHC's pattern-match compilation is naive, the > reordering will introduce 2 jumps into the common case of the > loop where none would be needed, right? Module Test(test) where test :: [a] -> Int test (a:b:c) = 2 test (a:[]) = 1 test [] = 0 gives the following cmm (with GHC 6.10.1 and -O2) Test_test_entry() { ... chn: if (Sp - 8 < SpLim) goto chp; // RTS stack check for space R1 = R2; I64[Sp - 8] = sgO_info; // Argument evaluation return address Sp = Sp - 8; if (R1 & 7 != 0) goto chs; // Is argument already evaluated? jump I64[R1] (); // No, evaluate it chp: R1 = Test_test_closure; // RTS stack expansion (GC?) jump stg_gc_fun (); chs: jump sgO_info (); // Yes, go directly to return address } sgO_ret() { ... chg: _chh = R1 & 7; // Constructor tag is in lower ptr bits if (_chh >= 2) goto chi; // Does the tag indicate (:)? R1 = Test_lvl2_closure+1; // No, load up closure for 0 and return Sp = Sp + 8; jump (I64[Sp + 0]) (); chi: R1 = I64[R1 + 14]; // Yes, get the tail of (:) I64[Sp + 0] = sgQ_info; // Tail evaluation return address if (R1 & 7 != 0) goto chl; // Is tail already evaluated? jump I64[R1] (); // No, evaluate it chl: jump sgQ_info (); // Yes, go directly to return address } sgQ_ret() { ... cha: _chb = R1 & 7; // Constructor tag is in lower ptr bits if (_chb >= 2) goto chc; // Does the tag indicate (:)? R1 = Test_lvl1_closure+1; // No, load up closure for 1 and return Sp = Sp + 8; jump (I64[Sp + 0]) (); chc: R1 = Test_lvl_closure+1; // Yes, load up closure for 2 and return Sp = Sp + 8; jump (I64[Sp + 0]) (); } Thus the trip is more like (assuming the first two (:) are already evaluated) test -> chs (WHNF check -- i.e., first (:) is already evaluated) chs -> sgO sg0 -> chi (constructor check -- i.e., not []) chi -> chl (WHNF check -- i.e., second (:) is already evaluated) chl -> sgQ sgQ -> chc (constructor check -- i.e., not (a:[])) chc -> return Looking at the assembler, things are a bit better in that the the gotos that immediately execute a jump are just replaced with a jump. For example, the assembler for test gives (test -> chs -> sg0 is replaced with test -> sg0) ... Test_test_info: .Lchn: leaq -8(%rbp),%rax // RTS stack check for return address cmpq %r14,%rax jb .Lchp movq %rsi,%rbx movq $sgO_info,-8(%rbp) // Argument evaluation return address addq $-8,%rbp testq $7,%rbx // Is argument already evaluated? jne sgO_info // Yes, go directly to return address jmp *(%rbx) // No, evaluate it .Lchp: movl $Test_test_closure,%ebx // RTS stack expansion (GC?) jmp *-8(%r13) ... sgO_info: .Lchg: movq %rbx,%rax // Constructor tag is in lower ptr bits andq $7,%rax cmpq $2,%rax // Does the tag indicate (:)? jae .Lchi movl $Test_lvl2_closure+1,%ebx// No, load up closure for 0 and return addq $8,%rbp jmp *(%rbp) .Lchi: movq 14(%rbx),%rbx // Yes, get the tail of (:) movq $sgQ_info,(%rbp) // Tail evaluation return address testq $7,%rbx // Is tail already evaluated? jne sgQ_info // No, evaluate it jmp *(%rbx) // Yes, go directly to return address ... Thus you actually get test -> sg0 (WHNF check -- i.e., first (:) is already evaluated) sg0 -> chi (constructor check -- i.e., not []) chi -> sgQ (WHNF check -- i.e., second (:) is already evaluated) sgQ -> chc (constructor check -- i.e., not (a:[])) chc -> return I guess this is a long winded way of saying that the branches are being ordered such that the fall though case is not the one that you put first, which, if I recall correctly, is somewhat bad as the x86 branch predictor guesses a forward branch that hasn't been seen before will fall through. Perhaps they are being ordered by the constructor tag? Cheers! -Tyson PS: I reversed GHC's ordering of test, sgO, and sgQ for readability above. The test -> sg0 and chi -> sgQ jumps actually go backwards, which is actually what you want because, if I recall correctly, the x86 branch predictor guesses a backwards branch it hasn't seen before will not fall through. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090323/f3b0def7/attachment.bin From colinpauladams at googlemail.com Tue Mar 24 04:00:10 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Tue Mar 24 03:47:48 2009 Subject: Puzzling (to me) type error message Message-ID: <1afdeaec0903240100v6363fa0cm9bf921f8335d416b@mail.gmail.com> I'm trying out concurrent haskell (never mind that the code isn't actually very concurrent - I'm just trying to get things to compile first). So with the following code, I get: play_move :: IORef Game_state -> IO () play_move game_state_ior = do (_, state, _) <- readIORef game_state_ior putStr "Playing AI: " start_time <- getCurrentTime ai_in_channel <- newChan ai_out_channel <- newChan writeChan ai_in_channel state ai_thread_id <- forkIO (run_ai ai_in_channel ai_out_channel) move <- readChan ai_out_channel end_time <- move `seq` (modifyIORef game_state_ior $! update_interactive_from_move move) >> getCurrentTime putStrLn $ show $ (diffUTCTime end_time start_time) run_ai :: Chan Non_interactive_state -> Chan Move.Move -> IO () run_ai in_channel out_channel = do state <- readChan in_channel let move = recommended_move state writeChan out_channel move UI.hs:625:45: Not in scope: type constructor or class `Move.Move' If I then comment-out the type signature for run_ai, it compiles fine with the following warning message: UI.hs:626:0: Warning: Definition but no type signature for `run_ai' Inferred type: run_ai :: Chan Non_interactive_state -> Chan Move.Move -> IO () Ghc 6.10.1 on Mac OS X. What is going on? From batterseapower at hotmail.com Tue Mar 24 04:09:06 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Mar 24 03:56:41 2009 Subject: compilation of pattern-matching? In-Reply-To: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> Message-ID: <9d4d38820903240109g37845075p9f70bed85a288d96@mail.gmail.com> 2009/3/23 Claus Reinke : > I just noticed that GHC (6.11.20090320) seems to compile both > > f (a:b:c) = > f (a:[]) = f [] = > and > f [] = f (a:[]) = f (a:b:c) = > > to something like (looking at Core, but writing source) > > f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}} In Core, case alternatives are stored in an order determined by the "data constructor tag" of the thing being matched on - this is independent of the order you wrote them in the source code. I believe the reason for this is just to reduce the work done by the code generator a tiny bit (and it's sometimes handy to know that the default case, if any, is always the first alternative). I don't know if preserving the order of the alts as written by the user would be a significant gain for the code generator. Maybe codegen should just output those tests for data alternatives that contain a recursive use of the data type first - e.g. the cons constructor for lists or the branch constructor for trees? Cheers, Max From batterseapower at hotmail.com Tue Mar 24 04:10:44 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Tue Mar 24 03:58:20 2009 Subject: Puzzling (to me) type error message In-Reply-To: <1afdeaec0903240100v6363fa0cm9bf921f8335d416b@mail.gmail.com> References: <1afdeaec0903240100v6363fa0cm9bf921f8335d416b@mail.gmail.com> Message-ID: <9d4d38820903240110p1183858dwa0df4467b4469409@mail.gmail.com> 2009/3/24 Colin Adams : > UI.hs:625:45: Not in scope: type constructor or class `Move.Move' > > If I then comment-out the type signature for run_ai, it compiles fine > with the following warning message: > > UI.hs:626:0: > ? ?Warning: Definition but no type signature for `run_ai' > ? ? ? ? ? ? Inferred type: run_ai :: Chan Non_interactive_state > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-> Chan Move.Move > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-> IO () Have you actually imported the Move.Move type? GHC /can/ suggest a type signature that includes type constructors that you haven't imported, but which show up in e.g. the types of imported functions. Cheers, Max From colinpauladams at googlemail.com Tue Mar 24 04:18:32 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Tue Mar 24 04:06:08 2009 Subject: Puzzling (to me) type error message In-Reply-To: <9d4d38820903240110p1183858dwa0df4467b4469409@mail.gmail.com> References: <1afdeaec0903240100v6363fa0cm9bf921f8335d416b@mail.gmail.com> <9d4d38820903240110p1183858dwa0df4467b4469409@mail.gmail.com> Message-ID: <1afdeaec0903240118y6f803e2lb8d80696d000a1ee@mail.gmail.com> Oh, I see. I assumed that is was being re-exported by one of the other imports and was being pulled in like that. I added an explicit import for the type and it now compiles the signature. Thanks. 2009/3/24 Max Bolingbroke : > 2009/3/24 Colin Adams : >> UI.hs:625:45: Not in scope: type constructor or class `Move.Move' >> >> If I then comment-out the type signature for run_ai, it compiles fine >> with the following warning message: >> >> UI.hs:626:0: >> ? ?Warning: Definition but no type signature for `run_ai' >> ? ? ? ? ? ? Inferred type: run_ai :: Chan Non_interactive_state >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-> Chan Move.Move >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-> IO () > > Have you actually imported the Move.Move type? GHC /can/ suggest a > type signature that includes type constructors that you haven't > imported, but which show up in e.g. the types of imported functions. > > Cheers, > Max > From claus.reinke at talk21.com Tue Mar 24 07:30:02 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Mar 24 07:17:46 2009 Subject: compilation of pattern-matching? References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <9d4d38820903240109g37845075p9f70bed85a288d96@mail.gmail.com> Message-ID: <2A774452C8C7473E8874FC0FD3DE642F@cr3lt> [commented cmm and asm elided - thanks, though! Some examples like this would be helpful in the commentary (or are they there and I've not yet seen them?)] |I guess this is a long winded way of saying that the branches are being |ordered such that the fall though case is not the one that you put first, |which, if I recall correctly, is somewhat bad as the x86 branch predictor |guesses a forward branch that hasn't been seen before will fall through. | |Perhaps they are being ordered by the constructor tag? > In Core, case alternatives are stored in an order determined by the > "data constructor tag" of the thing being matched on - this is > independent of the order you wrote them in the source code. I believe > the reason for this is just to reduce the work done by the code > generator a tiny bit (and it's sometimes handy to know that the > default case, if any, is always the first alternative). > > I don't know if preserving the order of the alts as written by the > user would be a significant gain for the code generator. Maybe codegen > should just output those tests for data alternatives that contain a > recursive use of the data type first - e.g. the cons constructor for > lists or the branch constructor for trees? Ok, so the answer seems to be: yes, GHC ignores my preferences but modern branch prediction might make this issue less relevant than it was in the early days?-) The recursive-case-first heuristic sounds useful, but not all pattern-match recursions fall into the fold-over-recursive-type category (see attached test). And what about different processors, with differing branch-prediction capabilities? I've attached an attempt at a test program, using Either with various options for testing Left first vs Right first on data with varying ratios of Left vs Right, and varying "predicability". The effect seems small here (Pentium M760, 2 GHz), not zero (5-8%), but not easily predictable, eg the largest effect so far was where I expected none at all: rml 1000000000 2: 0m47.632s rmr 1000000000 2: 0m44.150s (that should be a rightfirst match with equal mix Left and Right, so perhaps we need a different test?) There does seem to be a visible effect of ~5% between leftfirst and rightfirst in the extreme all-Left/Right cases, though, suggesting that the source order should be preserved to give programmers control over this, in spite of recent processors. What are the results elsewhere? Claus -------------- next part -------------- A non-text attachment was scrubbed... Name: PMorder.hs Type: application/octet-stream Size: 1176 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090324/c152668a/PMorder.obj From lennart at augustsson.net Tue Mar 24 07:47:16 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Mar 24 07:34:51 2009 Subject: compilation of pattern-matching? In-Reply-To: <2A774452C8C7473E8874FC0FD3DE642F@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <9d4d38820903240109g37845075p9f70bed85a288d96@mail.gmail.com> <2A774452C8C7473E8874FC0FD3DE642F@cr3lt> Message-ID: The only way to see the impact of very low level things like which way branches go is to generate assembly code and the make simple controlled changes of that. But even doing that is very dodgy since you are subject to the whims of cache misses etc. As far as branching goes, conditional branches that are in loops and that almost always go the same way are free on all modern processors. The branch predictor will learn quickly which way the the branch goes and prefetch along the right path. -- Lennart On Tue, Mar 24, 2009 at 11:30 AM, Claus Reinke wrote: > [commented cmm and asm elided - thanks, though! Some examples > like this would be helpful in the commentary (or are they there and > I've not yet seen them?)] > > |I guess this is a long winded way of saying that the branches are being > |ordered such that the fall though case is not the one that you put first, > |which, if I recall correctly, is somewhat bad as the x86 branch predictor > |guesses a forward branch that hasn't been seen before will fall through. > | > |Perhaps they are being ordered by the constructor tag? > >> In Core, case alternatives are stored in an order determined by the >> "data constructor tag" of the thing being matched on - this is >> independent of the order you wrote them in the source code. I believe >> the reason for this is just to reduce the work done by the code >> generator a tiny bit (and it's sometimes handy to know that the >> default case, if any, is always the first alternative). >> >> I don't know if preserving the order of the alts as written by the >> user would be a significant gain for the code generator. Maybe codegen >> should just output those tests for data alternatives that contain a >> recursive use of the data type first - e.g. the cons constructor for >> lists or the branch constructor for trees? > > Ok, so the answer seems to be: yes, GHC ignores my preferences > but modern branch prediction might make this issue less relevant > than it was in the early days?-) The recursive-case-first heuristic > sounds useful, but not all pattern-match recursions fall into the > fold-over-recursive-type category (see attached test). And what about > different processors, with differing branch-prediction capabilities? > > I've attached an attempt at a test program, using Either with various > options for testing Left first vs Right first on data with varying ratios > of Left vs Right, and varying "predicability". The effect seems small > here (Pentium M760, 2 GHz), not zero (5-8%), but not easily predictable, eg > the largest effect so far was where I expected none at all: > > ? rml 1000000000 2: 0m47.632s > ? rmr 1000000000 2: 0m44.150s > > (that should be a rightfirst match with equal mix Left and Right, > so perhaps we need a different test?) > > There does seem to be a visible effect of ~5% between leftfirst > and rightfirst in the extreme all-Left/Right cases, though, suggesting that > the source order should be preserved to give programmers control over this, > in spite of recent processors. What are the results elsewhere? > > Claus > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From bulat.ziganshin at gmail.com Tue Mar 24 14:22:57 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Mar 24 14:10:39 2009 Subject: [Haskell-cafe] GHC 6.10.2 - PCap package - affected by the change of Finalizers? In-Reply-To: References: Message-ID: <1683303028.20090324212257@gmail.com> Hello Neil, Tuesday, March 24, 2009, 9:08:08 PM, you wrote: one more case > Looks like pcap package needs a little tweek for 6.10.2 - programs > compiled with it bomb out with > ......error: a C finalizer called back into Haskell. > use Foreign.Concurrent.newForeignPtr for Haskell finalizers. > Is my interpretation of this error message correct? > Cheers > Neil > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Tue Mar 24 14:29:30 2009 From: dons at galois.com (Don Stewart) Date: Tue Mar 24 14:18:01 2009 Subject: [Haskell-cafe] GHC 6.10.2 - PCap package - affected by the change of Finalizers? In-Reply-To: <1683303028.20090324212257@gmail.com> References: <1683303028.20090324212257@gmail.com> Message-ID: <20090324182929.GD6470@whirlpool.galois.com> bulat.ziganshin: > Hello Neil, > > Tuesday, March 24, 2009, 9:08:08 PM, you wrote: > > one more case 0.16% percent of Hackage! From jnf at arcor.de Tue Mar 24 18:29:39 2009 From: jnf at arcor.de (jutaro) Date: Tue Mar 24 18:17:13 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <49C54E9D.9070309@gmail.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> <49C223AB.2090800@gmail.com> <22608413.post@talk.nabble.com> <20090319233409.GC12301@whirlpool.galois.com> <409849831.20090320131153@gmail.com> <49C54E9D.9070309@gmail.com> Message-ID: <22691289.post@talk.nabble.com> This is the first answer I got from the gtk2hs mailing list. Please consider this issue seriously. J?rgen Axel Simon wrote: > > > Phew, > > I think we're doomed. We have many, many little methods that take a > user-given function, wrap it into a foreign export wrapper which is > freed by using an on-destroy callback to Haskell. These functions are > most likely installed into some widgets (or other reference-counted > objects) that will be eventually destroyed by the Haskell garbage > collector. So, basically, we can't easily change Gtk2Hs. It will > involve many modifications. I can understand that not allowing > callbacks during GC is a great simplification in the runtime but it > seemed to be common practice to free Stable and function pointers > from within Haskell using a callback. > > So, unless I'm wrong on why finalizers call back into Haskell land, > then this means that Gtk2Hs is fundamentally broken for the > foreseeable future. > > Axel. > -- View this message in context: http://www.nabble.com/ANNOUNCE%3A-GHC-6.10.2-Release-Candidate-1-tp22524567p22691289.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From chak at cse.unsw.edu.au Tue Mar 24 21:16:43 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Mar 24 21:04:19 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <22691289.post@talk.nabble.com> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> <49C223AB.2090800@gmail.com> <22608413.post@talk.nabble.com> <20090319233409.GC12301@whirlpool.galois.com> <409849831.20090320131153@gmail.com> <49C54E9D.9070309@gmail.com> <22691289.post@talk.nabble.com> Message-ID: <6A1AF7E6-0F47-487A-82B9-A0658632589F@cse.unsw.edu.au> jutaro: > This is the first answer I got from the gtk2hs mailing list. Please > consider > this issue seriously. Well there is a simple fix as Simon Marlow wrote, > The fix is fiarly easy: use Foreign.Concurrent.mkForeignPtr with a > foreign import. In fact, if as Axel writes, these finalisers are Haskell functions that are exported using foreign import wrapper, then using Foreign.Concurrent.mkForeignPtr is actually the *simpler* thing to do (you don't need any wrapping and exporting). Manuel > Axel Simon wrote: >> >> >> Phew, >> >> I think we're doomed. We have many, many little methods that take a >> user-given function, wrap it into a foreign export wrapper which is >> freed by using an on-destroy callback to Haskell. These functions are >> most likely installed into some widgets (or other reference-counted >> objects) that will be eventually destroyed by the Haskell garbage >> collector. So, basically, we can't easily change Gtk2Hs. It will >> involve many modifications. I can understand that not allowing >> callbacks during GC is a great simplification in the runtime but it >> seemed to be common practice to free Stable and function pointers >> from within Haskell using a callback. >> >> So, unless I'm wrong on why finalizers call back into Haskell land, >> then this means that Gtk2Hs is fundamentally broken for the >> foreseeable future. >> >> Axel. From simonpj at microsoft.com Wed Mar 25 05:18:08 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Mar 25 05:05:54 2009 Subject: compilation of pattern-matching? In-Reply-To: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> Indeed GHC does not attempt to retain the order of alternatives, although a) it might be possible to do so by paying more attention in numerous places b) GHC may do so already, by accident, in certain cases Observations: * The issue at stake is a small one: not the *number of tests* but *which tests branch, and which fall through*. * Simply ordering the equations doesn't really work, because pattern-match compilation will match an entire column at once: f (x:xs) True = ... f [] True = ... f [] False = ... f (x:xs) False = ... Which "order" should the (:)/[] test go in? * Not only does GHC currently not attempt to retain order, but for a particular order it makes no guarantees about which falls through. For example, given case ... of { A -> e1; C -> e2; B -> e3 } We might test for A and then either fall though to e1 or fall through to the test for C * When the number of constructors is larger, instead of a linear sequence of tests, GHC may generate a table-jump; or a balanced tree of tests. * Which plan performs best is tremendously architecture dependent, and may well vary a lot between different chips implementing the same instruction set. It's a losing battle to fix the strategy in source code. * More promising might be to say "this is the hot branch". That information about frequency could in principle be used by the back end to generate better code. However, I am unsure how a) to express this info in source code b) retain it throughout optimisation Claus, if you think this thread is worth capturing, then do write a Commentary page, and I'll check its veracity. Thanks Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Claus Reinke | Sent: 23 March 2009 23:17 | To: glasgow-haskell-users@haskell.org | Subject: compilation of pattern-matching? | | I just noticed that GHC (6.11.20090320) seems to compile both | | f (a:b:c) = | f (a:[]) = | f [] = | | and | | f [] = | f (a:[]) = | f (a:b:c) = | | to something like (looking at Core, but writing source) | | f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}} | | That doesn't seem right to me: if I try to give the patterns in | the order from frequent to rare, in order to reduce jumps, I | don't expect GHC to rearrange things. What is the rationale | for this? And where can I read about GHC's pattern match | compilation approach in general? | | Claus | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From lennart at augustsson.net Wed Mar 25 06:41:40 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Mar 25 06:29:14 2009 Subject: compilation of pattern-matching? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: You could imagine a pragma to say which branch is likely. f p1 = e1 f p2 = {-# LIKELY #-} e2 f p3 = e3 Is there some way to propagate pragmas through core transformations? -- Lennart On Wed, Mar 25, 2009 at 9:18 AM, Simon Peyton-Jones wrote: > Indeed GHC does not attempt to retain the order of alternatives, although > a) it might be possible to do so by paying more attention in numerous places > b) GHC may do so already, by accident, in certain cases > > Observations: > > * The issue at stake is a small one: not the *number of tests* but *which tests branch, and which fall through*. > > * Simply ordering the equations doesn't really work, because pattern-match compilation will match an entire column at once: > ? f (x:xs) True = ... > ? f [] ? ? True = ... > ? f [] ? ? False = ... > ? f (x:xs) False = ... > Which "order" should the (:)/[] test go in? > > * Not only does GHC currently not attempt to retain order, but for a particular order it makes no guarantees about which falls through. ?For example, given > ? ? ? ?case ... of { A -> e1; C -> e2; B -> e3 } > We might test for A and then > either fall though to e1 > or ? ? fall through to the test for C > > * When the number of constructors is larger, instead of a linear sequence of tests, GHC may generate a table-jump; or a balanced tree of tests. > > * Which plan performs best is tremendously architecture dependent, and may well vary a lot between different chips implementing the same instruction set. ?It's a losing battle to fix the strategy in source code. > > * More promising might be to say "this is the hot branch". ?That information about frequency could in principle be used by the back end to generate better code. ?However, I am unsure how > ? ? ? ?a) to express this info in source code > ? ? ? ?b) retain it throughout optimisation > > > Claus, if you think this thread is worth capturing, then do write a Commentary page, and I'll check its veracity. > > Thanks > > Simon > > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Claus Reinke > | Sent: 23 March 2009 23:17 > | To: glasgow-haskell-users@haskell.org > | Subject: compilation of pattern-matching? > | > | I just noticed that GHC (6.11.20090320) seems to compile both > | > | f (a:b:c) = > | f (a:[]) = > | f [] = > | > | and > | > | f [] = > | f (a:[]) = > | f (a:b:c) = > | > | to something like (looking at Core, but writing source) > | > | f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}} > | > | That doesn't seem right to me: if I try to give the patterns in > | the order from frequent to rare, in order to reduce jumps, I > | don't expect GHC to rearrange things. What is the rationale > | for this? And where can I read about GHC's pattern match > | compilation approach in general? > | > | Claus > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From simonpj at microsoft.com Wed Mar 25 07:03:47 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Mar 25 06:51:20 2009 Subject: compilation of pattern-matching? In-Reply-To: References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C334CBCEC08C@EA-EXMSG-C334.europe.corp.microsoft.com> | You could imagine a pragma to say which branch is likely. | f p1 = e1 | f p2 = {-# LIKELY #-} e2 | f p3 = e3 | | Is there some way to propagate pragmas through core transformations? Not robustly. We do have "Notes" attached to core, which are more or less propagated though, but I make not promises. It's quite unclear how to make all optimsations treat annotations in the "right" way. Simon From greenrd at greenrd.org Tue Mar 24 18:59:52 2009 From: greenrd at greenrd.org (Robin Green) Date: Wed Mar 25 07:36:56 2009 Subject: strace breaks cabal - how to find the problem? Message-ID: <20090324225952.1d88af0a@greenrd.org> On my obscure configuration (GHC 6.10.1, with pkgenv activated, on Fedora Linux rawhide running on a VirtualBox x86 VM with hardware virtualisation enabled), running strace on cabal causes it to misbehave, as described below. I don't know whether this is due to a bug in cabal, the GHC runtime, strace, the Linux kernel, VirtualBox, or my processor's virtualization support. Not sure how to proceed to debug this. Perhaps someone else could try this, on their configuration, and report what they find? This command is ran in an untarred copy of hs-bibutils 0.1 (not that it matters): strace -f -e trace=file cabal install --extra-include-dirs=../bibutils_4.1/lib/ 2>&1|cat >cabal.strace Cabal fails to determine the version of ghc-pkg (or sometimes ghc), and stops, complaining that it can't verify that the version of ghc(-pkg) is the required one. ghc-pkg is execve'd, but something goes wrong - not sure what. -- Robin From igloo at earth.li Wed Mar 25 08:58:52 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Mar 25 08:46:24 2009 Subject: Problem with a second installed version of the syb package In-Reply-To: <52f14b210903230253p120a50c6v826cc59bcc635363@mail.gmail.com> References: <52f14b210903200133w43152ab0rcf8bd78eb964d111@mail.gmail.com> <20090320233930.GA8825@matrix.chaos.earth.li> <52f14b210903230253p120a50c6v826cc59bcc635363@mail.gmail.com> Message-ID: <20090325125852.GA10162@matrix.chaos.earth.li> On Mon, Mar 23, 2009 at 10:53:19AM +0100, Jos? Pedro Magalh?es wrote: > > Bad interface file: C:\Program Files > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi > Something is amiss; requested module syb:Data.Generics differs from > name found in the interface file syb-0.2.0.0:Data.Generics > Failed, modules loaded: none. > > ghc --show-iface "C:\Program Files > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi" says: > > interface syb-0.2.0.0:Data.Generics 610120090314 It looks like this was built with -package-name syb-0.2.0.0, but it should be built with -package-name syb. There should be ghc-options: -package-name syb in the .cabal file to make this happen. Thanks Ian From marlowsd at gmail.com Wed Mar 25 09:12:46 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Mar 25 09:00:26 2009 Subject: strace breaks cabal - how to find the problem? In-Reply-To: <20090324225952.1d88af0a@greenrd.org> References: <20090324225952.1d88af0a@greenrd.org> Message-ID: <49CA2DCE.5080605@gmail.com> Robin Green wrote: > On my obscure configuration (GHC 6.10.1, with pkgenv activated, on > Fedora Linux rawhide running on a VirtualBox x86 VM with hardware > virtualisation enabled), running strace on cabal causes it to > misbehave, as described below. > > I don't know whether this is due to a bug in cabal, the GHC > runtime, strace, the Linux kernel, VirtualBox, or my processor's > virtualization support. Not sure how to proceed to debug this. Perhaps > someone else could try this, on their configuration, and report what > they find? > > This command is ran in an untarred copy of hs-bibutils 0.1 (not that it > matters): > > strace -f -e trace=file cabal install > --extra-include-dirs=../bibutils_4.1/lib/ 2>&1|cat >cabal.strace > > Cabal fails to determine the version of ghc-pkg (or sometimes ghc), and > stops, complaining that it can't verify that the version of ghc(-pkg) > is the required one. ghc-pkg is execve'd, but something goes wrong - > not sure what. This sounds slightly familiar. The System.Process library uses vfork() on Unix systems, which as it turns out helps to avoid some race conditions. However, while debugging something in this area recently (using strace) I remember seeing different behaviour when running under strace. I suspect that strace is doing something to vfork(). Perhaps we should bite the bullet and use fork(), and fix the race conditions properly. As I recall, what was happening was that the fork() took so long that it got interrupted by the timer signal (1/50 secs), and restarted, ad infinitum. So in order to use fork() we have to disable timer signals (for the whole process? what if multiple threads are doing fork()? sigh.). Cheers, Simon From marlowsd at gmail.com Wed Mar 25 09:39:24 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Mar 25 09:27:03 2009 Subject: ANNOUNCE: GHC 6.10.2 Release Candidate 1 In-Reply-To: <6A1AF7E6-0F47-487A-82B9-A0658632589F@cse.unsw.edu.au> References: <20090315155142.GA18000@matrix.chaos.earth.li> <22592804.post@talk.nabble.com> <49C223AB.2090800@gmail.com> <22608413.post@talk.nabble.com> <20090319233409.GC12301@whirlpool.galois.com> <409849831.20090320131153@gmail.com> <49C54E9D.9070309@gmail.com> <22691289.post@talk.nabble.com> <6A1AF7E6-0F47-487A-82B9-A0658632589F@cse.unsw.edu.au> Message-ID: <49CA340C.1080700@gmail.com> Manuel M T Chakravarty wrote: > jutaro: >> This is the first answer I got from the gtk2hs mailing list. Please >> consider >> this issue seriously. > > Well there is a simple fix as Simon Marlow wrote, >> The fix is fiarly easy: use Foreign.Concurrent.mkForeignPtr with a >> foreign import. > > In fact, if as Axel writes, these finalisers are Haskell functions that > are exported using foreign import wrapper, then using > Foreign.Concurrent.mkForeignPtr is actually the *simpler* thing to do > (you don't need any wrapping and exporting). Right. Admittedly we hadn't realised that this would affect gtk2hs when we decided to bring this change into 6.10.2, and if we had, perhaps we would have decided to wait until 6.12.1. Patchlevel releases are not supposed to break existing working code - however in this case the code that is broken is using undocumented features. So we *could* back out the change. let's talk about whether that's the right course of action. There's a GHC meeting this afternoon, come long to #ghc on Freenode at 1600 UTC (in just under 2.5 hours). To summarise the issues: * gtk2hs is broken by this change, and possibly others. Unfortunately we can't easily find out whether code is affected, because this is a dynamic property. * gtk2hs can be fixed, but that means doing a new release etc. * the error message is pretty clear (not a crash) * there was some demand for the new feature (e.g Conal Elliot). If we back out, then these people will have to wait until 6.12.1 (~ 6 months). * backing out now will delay the GHC release. Cheers, Simon From jpm at cs.uu.nl Wed Mar 25 10:43:42 2009 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Wed Mar 25 10:31:31 2009 Subject: Problem with a second installed version of the syb package In-Reply-To: <20090325125852.GA10162@matrix.chaos.earth.li> References: <52f14b210903200133w43152ab0rcf8bd78eb964d111@mail.gmail.com> <20090320233930.GA8825@matrix.chaos.earth.li> <52f14b210903230253p120a50c6v826cc59bcc635363@mail.gmail.com> <20090325125852.GA10162@matrix.chaos.earth.li> Message-ID: <52f14b210903250743i26c945b1n63a7457195304b78@mail.gmail.com> Hello Ian, 2009/3/25 Ian Lynagh > On Mon, Mar 23, 2009 at 10:53:19AM +0100, Jos? Pedro Magalh?es wrote: > > > > Bad interface file: C:\Program Files > > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi > > Something is amiss; requested module syb:Data.Generics differs > from > > name found in the interface file syb-0.2.0.0:Data.Generics > > Failed, modules loaded: none. > > > > ghc --show-iface "C:\Program Files > > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi" says: > > > > interface syb-0.2.0.0:Data.Generics 610120090314 > > It looks like this was built with -package-name syb-0.2.0.0, but it > should be built with -package-name syb. There should be > ghc-options: -package-name syb > in the .cabal file to make this happen. Yes, that works, thanks. I thought this problem was caused by having the syb package unversioned in the GHC repo, and I also thought that that had changed, but now I see that the flag -package-name syb is still there. Would you know if this necessary for some reason? Thanks, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090325/4163a688/attachment-0001.htm From marlowsd at gmail.com Wed Mar 25 11:55:52 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Mar 25 11:43:30 2009 Subject: compilation of pattern-matching? In-Reply-To: References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <49CA5408.50905@gmail.com> (thanks to Simon PJ for an excellent summary of the issues) Lennart Augustsson wrote: > You could imagine a pragma to say which branch is likely. > f p1 = e1 > f p2 = {-# LIKELY #-} e2 > f p3 = e3 > > Is there some way to propagate pragmas through core transformations? I just thought I'd mention the way gcc does this: if (__builtin_expect__(p, 1)) { ... likely case ... } else { ... unlikely case ... } sadly gcc's back end doesn't alway take advantage of the information very well, at least when I've tried it, but I think the design is nice - it feels more general than just annotating the "hot code". Or perhaps it feels nicer because an annotation on the hot code would have to be propagated back through the branches; and how far back? What if there are multiple branches annotated as "hot"? Cheers, Simon > -- Lennart > > On Wed, Mar 25, 2009 at 9:18 AM, Simon Peyton-Jones > wrote: >> Indeed GHC does not attempt to retain the order of alternatives, although >> a) it might be possible to do so by paying more attention in numerous places >> b) GHC may do so already, by accident, in certain cases >> >> Observations: >> >> * The issue at stake is a small one: not the *number of tests* but *which tests branch, and which fall through*. >> >> * Simply ordering the equations doesn't really work, because pattern-match compilation will match an entire column at once: >> f (x:xs) True = ... >> f [] True = ... >> f [] False = ... >> f (x:xs) False = ... >> Which "order" should the (:)/[] test go in? >> >> * Not only does GHC currently not attempt to retain order, but for a particular order it makes no guarantees about which falls through. For example, given >> case ... of { A -> e1; C -> e2; B -> e3 } >> We might test for A and then >> either fall though to e1 >> or fall through to the test for C >> >> * When the number of constructors is larger, instead of a linear sequence of tests, GHC may generate a table-jump; or a balanced tree of tests. >> >> * Which plan performs best is tremendously architecture dependent, and may well vary a lot between different chips implementing the same instruction set. It's a losing battle to fix the strategy in source code. >> >> * More promising might be to say "this is the hot branch". That information about frequency could in principle be used by the back end to generate better code. However, I am unsure how >> a) to express this info in source code >> b) retain it throughout optimisation >> >> >> Claus, if you think this thread is worth capturing, then do write a Commentary page, and I'll check its veracity. >> >> Thanks >> >> Simon >> >> >> | -----Original Message----- >> | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- >> | bounces@haskell.org] On Behalf Of Claus Reinke >> | Sent: 23 March 2009 23:17 >> | To: glasgow-haskell-users@haskell.org >> | Subject: compilation of pattern-matching? >> | >> | I just noticed that GHC (6.11.20090320) seems to compile both >> | >> | f (a:b:c) = >> | f (a:[]) = >> | f [] = >> | >> | and >> | >> | f [] = >> | f (a:[]) = >> | f (a:b:c) = >> | >> | to something like (looking at Core, but writing source) >> | >> | f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}} >> | >> | That doesn't seem right to me: if I try to give the patterns in >> | the order from frequent to rare, in order to reduce jumps, I >> | don't expect GHC to rearrange things. What is the rationale >> | for this? And where can I read about GHC's pattern match >> | compilation approach in general? >> | >> | Claus >> | >> | _______________________________________________ >> | Glasgow-haskell-users mailing list >> | Glasgow-haskell-users@haskell.org >> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From allbery at ece.cmu.edu Wed Mar 25 12:37:53 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Mar 25 12:25:38 2009 Subject: strace breaks cabal - how to find the problem? In-Reply-To: <49CA2DCE.5080605@gmail.com> References: <20090324225952.1d88af0a@greenrd.org> <49CA2DCE.5080605@gmail.com> Message-ID: <43511719-3C10-481A-B41E-C0E5C5AB5E0F@ece.cmu.edu> On 2009 Mar 25, at 9:12, Simon Marlow wrote: > Robin Green wrote: > This sounds slightly familiar. The System.Process library uses > vfork() on Unix systems, which as it turns out helps to avoid some > race conditions. However, while debugging something in this area > recently (using strace) I remember seeing different behaviour when > running under strace. I suspect that strace is doing something to > vfork(). strace and vfork don't mix; vfork uses a hack that won't work right when tracing is enabled. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090325/5cc5a4b6/PGP.bin From claus.reinke at talk21.com Wed Mar 25 14:01:24 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 25 13:49:03 2009 Subject: compilation of pattern-matching? References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <68D4104586604A2090EF7421DF3A6730@cr3lt> >Indeed GHC does not attempt to retain the order of alternatives, although >a) it might be possible to do so by paying more attention in numerous places >b) GHC may do so already, by accident, in certain cases That adds even more unpredictability. One thing that I don't want whenever I have to care about performance is small changes having odd/unexplainable effects (I vaguely recall a case where removing an unused parameter from a recursion made the program slower, or eliminating returned constructors by using continuations made one inner-loop function faster, another slower..). Lennart is of course right: even if GHC would respect the ordering indicated in my source program, I might not be able to tune that source to make good use of even a single target processor (I tried defining a foldl over a user-defined List type, so that I could switch the order of Nil/Cons, and hence the test order used by GHC, and found the Nil-before-Cons order to be 2-3% faster for folding a very long list than the Cons-before-Nil order I wanted), but it is very frustrating if I'm not even given the chance because GHC sorts the alternatives, not even according to its own interpretation of branching performance, but completely arbitrarily!-) >* The issue at stake is a small one: not the *number of tests* but >*which tests branch, and which fall through*. Right on the issue, but I'm not quite sure how small it is: the test case source I attached a few messages ago consistently showed one ordering to be 5% faster than the other for the extreme case of one test nearly always failing. There may well be more profitable optimizations remaining to be implemented first - what disturbs me is that Haskell code is full of conditionals and matches, which I tend to arrange according to expected frequency, and GHC simply ignores all those hints. With the hint about branch prediction, I also found this old ticket (which seems to have been waiting for the new backend, and indicates rather larger performance differences): Offer control over branch prediction http://hackage.haskell.org/trac/ghc/ticket/849 >* Simply ordering the equations doesn't really work, because >pattern-match compilation will match an entire column at once: > f (x:xs) True = ... > f [] True = ... > f [] False = ... > f (x:xs) False = ... >Which "order" should the (:)/[] test go in? In the order indicated in the source!? The usual pattern-match optimizations should not change that, they will just skip the two '[]' cases if the list isn't empty, or use the constructor tag to jump directly to a sub-column. Haskell specifies left-to-right, top-down. >* Not only does GHC currently not attempt to retain order, >but for a particular order it makes no guarantees about which >falls through. For example, given > case ... of { A -> e1; C -> e2; B -> e3 } >We might test for A and then >either fall though to e1 >or fall through to the test for C That is the part I missed, and which might give the UNLIKELY pragma, as suggested in #849, more expressive power than plain clause ordering. However, since Haskell specifies a match order, I don't see why that couldn't be used as the basis for mapping to branches as well, with the clauses listed in decreasing likelyhood, and GHC generating the branch predictions and fallthroughs to match this information to the target processor characteristics? >* When the number of constructors is larger, instead of a linear >sequence of tests, GHC may generate a table-jump; or a >balanced tree of tests. The table-jump would make all alternatives equally costly/fast, with no penalty for adding infrequent alternatives, right? The balanced tree sounds like one of the pattern-match state machines, and there would still be room for representing expected frequency in terms of tree-path/-rotation/-representation. >* Which plan performs best is tremendously architecture >dependent, and may well vary a lot between different chips >implementing the same instruction set. It's a losing battle to >fix the strategy in source code. >* More promising might be to say "this is the hot branch". >That information about frequency could in principle be >used by the back end to generate better code. However, >I am unsure how > a) to express this info in source code > b) retain it throughout optimisation So it should be specified in the source, after all, just in a way that gives programmers room to express their knowledge while leaving GHC free to implement that knowledge on the target. Things like the UNLIKELY pragma would seem useful, if attached to decisions: unless GHC can optimize the whole decision away, it will remain throughout optimization, and come out as some form of branch, with the hint still attached. But UNLIKELY only covers the most common case (marking alternatives with minimal expected frequency) - if clause ordering was respected, relative frequencies of alternatives could be specified without pragmas, just by ordering pattern-match or conditional clauses according to expected frequency. >Claus, if you think this thread is worth capturing, then do >write a Commentary page, and I'll check its veracity. Given the existence of #849, I've just linked this thread from there. Claus From lennart at augustsson.net Wed Mar 25 14:41:24 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Mar 25 14:28:56 2009 Subject: compilation of pattern-matching? In-Reply-To: <68D4104586604A2090EF7421DF3A6730@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> Message-ID: When you tried switching Nil and Cons, did you try it on many examples? For a single example a 2-3% could be easily attributed to random effects like different instruction cache hit patterns. If you get it consistently over several programs then it seems likely to mean something, but I'm not sure what. On Wed, Mar 25, 2009 at 6:01 PM, Claus Reinke wrote: >> Indeed GHC does not attempt to retain the order of alternatives, although >> a) it might be possible to do so by paying more attention in numerous >> places >> b) GHC may do so already, by accident, in certain cases > > That adds even more unpredictability. One thing that I don't want whenever I > have to care about performance is small changes > having odd/unexplainable effects (I vaguely recall a case where removing an > unused parameter from a recursion made the program > slower, or eliminating returned constructors by using continuations > made one inner-loop function faster, another slower..). > Lennart is of course right: even if GHC would respect the ordering indicated > in my source program, I might not be able to tune that source to make good > use of even a single target processor (I tried defining a foldl over a > user-defined List type, so that I could switch > the order of Nil/Cons, and hence the test order used by GHC, and found the > Nil-before-Cons order to be 2-3% faster for folding a > very long list than the Cons-before-Nil order I wanted), but it is very > frustrating if I'm not even given the chance because GHC > sorts the alternatives, not even according to its own interpretation > of branching performance, but completely arbitrarily!-) > >> * The issue at stake is a small one: not the *number of tests* but *which >> tests branch, and which fall through*. > > Right on the issue, but I'm not quite sure how small it is: the test > case source I attached a few messages ago consistently showed one ordering > to be 5% faster than the other for the extreme case > of one test nearly always failing. There may well be more profitable > optimizations remaining to be implemented first - what disturbs me is that > Haskell code is full of conditionals and matches, which I tend to arrange > according to expected frequency, and GHC simply ignores all those hints. > > With the hint about branch prediction, I also found this old ticket (which > seems to have been waiting for the new backend, and > indicates rather larger performance differences): > > ? Offer control ?over branch prediction > ? http://hackage.haskell.org/trac/ghc/ticket/849 > >> * Simply ordering the equations doesn't really work, because pattern-match >> compilation will match an entire column at once: >> ?f (x:xs) True = ... >> ?f [] ? ? True = ... >> ?f [] ? ? False = ... >> ?f (x:xs) False = ... >> Which "order" should the (:)/[] test go in? > > In the order indicated in the source!? The usual pattern-match > optimizations should not change that, they will just skip the two > '[]' cases if the list isn't empty, or use the constructor tag to jump > directly to a sub-column. Haskell specifies left-to-right, top-down. > >> * Not only does GHC currently not attempt to retain order, but for a >> particular order it makes no guarantees about which falls through. ?For >> example, given >> ? ? ? case ... of { A -> e1; C -> e2; B -> e3 } >> We might test for A and then >> either fall though to e1 >> or ? ? fall through to the test for C > > That is the part I missed, and which might give the UNLIKELY > pragma, as suggested in #849, more expressive power than > plain clause ordering. However, since Haskell specifies a match > order, I don't see why that couldn't be used as the basis for > mapping to branches as well, with the clauses listed in decreasing > likelyhood, and GHC generating the branch predictions and fallthroughs to > match this information to the target processor characteristics? > >> * When the number of constructors is larger, instead of a linear sequence >> of tests, GHC may generate a table-jump; or a balanced tree of tests. > > The table-jump would make all alternatives equally costly/fast, > with no penalty for adding infrequent alternatives, right? The > balanced tree sounds like one of the pattern-match state machines, and there > would still be room for representing expected frequency in terms of > tree-path/-rotation/-representation. > >> * Which plan performs best is tremendously architecture dependent, and may >> well vary a lot between different chips implementing the same instruction >> set. ?It's a losing battle to fix the strategy in source code. >> * More promising might be to say "this is the hot branch". ?That >> information about frequency could in principle be used by the back end to >> generate better code. ?However, I am unsure how >> ? ? ? a) to express this info in source code >> ? ? ? b) retain it throughout optimisation > > > So it should be specified in the source, after all, just in a way > that gives programmers room to express their knowledge while > leaving GHC free to implement that knowledge on the target. > > Things like the UNLIKELY pragma would seem useful, if > attached to decisions: unless GHC can optimize the whole decision away, it > will remain throughout optimization, and come out as some form of branch, > with the hint still attached. > > But UNLIKELY only covers the most common case > (marking alternatives with minimal expected frequency) - > if clause ordering was respected, relative frequencies of > alternatives could be specified without pragmas, just by > ordering pattern-match or conditional clauses according > to expected frequency. > >> Claus, if you think this thread is worth capturing, then do write a >> Commentary page, and I'll check its veracity. > > Given the existence of #849, I've just linked this thread > from there. > > Claus > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From simonpj at microsoft.com Wed Mar 25 15:39:23 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Mar 25 15:25:40 2009 Subject: compilation of pattern-matching? In-Reply-To: <68D4104586604A2090EF7421DF3A6730@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> | >Indeed GHC does not attempt to retain the order of alternatives, although | >a) it might be possible to do so by paying more attention in numerous places | >b) GHC may do so already, by accident, in certain cases | | That adds even more unpredictability. .... | very long list than the Cons-before-Nil order I wanted), but it is | very frustrating if I'm not even given the chance because GHC | sorts the alternatives, not even according to its own interpretation | of branching performance, but completely arbitrarily!-) All I'm saying is that GHC has never claimed to offer predictability here. I understand that you find it frustrating, but there it is. You are making a feature request. Good! Then someone needs to design it, and implement it in a way that is robust to the rather radical program optimizations that GHC does. I don't think either is straightforward, and at the moment I am snowed under. It is possible that such a change might allow you to tune programs better; although I doubt such tuning would be portable. (Your 5% figures are encouraging, but it's one thing to get a 5% gain on one program, and quite another to get a positive figure on every program. I spend a lot of time looking at nofib numbers where some programs respond well to some changed optimization, and others slow down.) I'm also a bit concerned that it would impose a new constraint on the entire compilation chain. Your idea of simply ordering patterns is certainly appealing from the programming point of view. I don't yet see how to propagate that information through the pattern compilation algorithm, retain the resulting information in the optimizer, and exploit it in a code generator. But it might well be possible. Maybe you can write a Haskell workshop paper about it? Simon's idea of an annotation that gives some idea of the likelihood of the value of an expression taking a particular form sounds promising for robustness. Something like Note "80% chance of (:), 20% of []" (f x) But it's not so good when there are multiple interacting parameters to a pattern match. Simon From ndmitchell at gmail.com Wed Mar 25 16:04:45 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Mar 25 15:52:16 2009 Subject: compilation of pattern-matching? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <404396ef0903251304y6758adf2i5c10eaf62210eb8f@mail.gmail.com> Hi > Your idea of simply ordering patterns is certainly appealing from the programming point of view. ?I don't yet see how to propagate that information through the pattern compilation algorithm, retain the resulting information in the optimizer, and exploit it in a code generator. ?But it might well be possible. Maybe you can write a Haskell workshop paper about it? I don't find ordering of patterns appealing, I find it scary! I order my patterns according to the semantics I desire, and then additionally by what looks pretty. I'd like it if whatever cleverness GHC can work is used rather than requiring me to think. If the order of patterns is to become important, it has to be with an explicit "look, I know something you don't" pragma rather than by default. As an example, I suspect that the "hot-path" on most list pattern matches is in the (:) case. I don't want to ever teach a user that (:) comes before [] because ... long spiel about branch prediction ... Controlling branch prediction will only ever be a niche activity, so the defaults should reflect that. Thanks Neil From jmaessen at alum.mit.edu Wed Mar 25 16:35:51 2009 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Wed Mar 25 16:23:35 2009 Subject: compilation of pattern-matching? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <0633DA8F-FAFC-46E5-87B5-485BDB4DD43C@alum.mit.edu> On Mar 25, 2009, at 5:18 AM, Simon Peyton-Jones wrote: > Indeed GHC does not attempt to retain the order of alternatives, > although > a) it might be possible to do so by paying more attention in > numerous places > b) GHC may do so already, by accident, in certain cases > > ... > * Which plan performs best is tremendously architecture dependent, > and may well vary a lot between different chips implementing the > same instruction set. It's a losing battle to fix the strategy in > source code. > > * More promising might be to say "this is the hot branch". That > information about frequency could in principle be used by the back > end to generate better code. However, I am unsure how > a) to express this info in source code > b) retain it throughout optimisation The usual compiler heuristic is "backward branches" or "loop edges", which I would re-interpret in Haskell as "contains a call (any call) to a function in the same SCC binding group". But I expect for hot code the effect would indeed be small. > Claus, if you think this thread is worth capturing, then do write a > Commentary page, and I'll check its veracity. > > Thanks > > Simon From claus.reinke at talk21.com Wed Mar 25 20:45:42 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 25 20:33:19 2009 Subject: compilation of pattern-matching? References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt> Message-ID: >When you tried switching Nil and Cons, did you try it on many examples? >For a single example a 2-3% could be easily attributed to random >effects like different instruction cache hit patterns. If you get it >consistently over several programs then it seems likely to mean >something, but I'm not sure what. Agreed. There is a fairly consistent pattern over experiment/size variations (eg, different times for different orderings), but the time differences themselves are too small for useful interpretation. I would need a way to see what is really going on on the processor (I'm sure there are such things - are there any free ones?) to make sure there are no other effects interfering, or I might as well measure a random generator. Claus From claus.reinke at talk21.com Wed Mar 25 21:09:23 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 25 20:57:00 2009 Subject: compilation of pattern-matching? References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: | very long list than the Cons-before-Nil order I wanted), but it is | very frustrating if I'm not even given the chance because GHC | sorts the alternatives, not even according to its own interpretation | of branching performance, but completely arbitrarily!-) >All I'm saying is that GHC has never claimed to offer predictability here. >I understand that you find it frustrating, but there it is. It is a programming habit from my early functional programming days, probably pre-Haskell, certainly from before I started using GHC. It just so happens that I've only recently started to get interested in performance-critical code again, so I'm only now finding out that the old habit doesn't fit for GHC (among other recent surprises with GHC optimizations, as you've noticed;-). I don't currently have sufficient data to support a feature request myself (benchmarking on my laptop is not a fun game unless the effects are fairly clear-cut - too much noise in the timing details), though #849 seemed to have more extreme numbers. I was just hoping that the "sorting" of case branches was an accident that could be switched off easily, as I can't see any benefit in it. If that wouldn't be easy, there are bigger fish to catch elsewhere, so I'm not suggesting to spend much time on this now. >Your idea of simply ordering patterns is certainly appealing >from the programming point of view. I don't yet see how to >propagate that information through the pattern compilation >algorithm, retain the resulting information in the optimizer, >and exploit it in a code generator. But it might well be possible. >Maybe you can write a Haskell workshop paper about it? Strange. I don't think it is my idea (older implementations used to work that way, and iirc, it also matches what Prolog systems used to do), and I didn't think it was anything but straightforward to avoid case transformations unless there is a clear benefit, so I doubt there is a useful paper in there (also, I can't afford to plan that far ahead atm). What is the benefit of changing the ordering (not just joining paths to avoid redundant tests, but actually modifying the order of tests, to sort by their order in the data type declaration)? Is there any documentation of these case transformations that I could look up? Claus From claus.reinke at talk21.com Wed Mar 25 21:38:55 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 25 21:26:43 2009 Subject: compilation of pattern-matching? References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0903251304y6758adf2i5c10eaf62210eb8f@mail.gmail.com> Message-ID: >I don't find ordering of patterns appealing, I find it scary! I order >my patterns according to the semantics I desire, and then additionally >by what looks pretty. I'd like it if whatever cleverness GHC can work >is used rather than requiring me to think. If the order of patterns is >to become important, it has to be with an explicit "look, I know >something you don't" pragma rather than by default. No need to be scared! As I mentioned, Haskell already specifies pattern match order left-to-right, top-to-bottom, so the declarative semantics wouldn't change one bit. I'm just suggesting to use the existing specification, in order to make the generated branching code somewhat more predictable. We don't know yet whether this would make a worthwhile difference, but if it would, then being able to express performance constraints without affecting the declarative semantics might seem more important than aesthetical considerations. Not to mention that the alternative would be to spoil your pretty code with pragmas!-) >As an example, I suspect that the "hot-path" on most list pattern >matches is in the (:) case. I don't want to ever teach a user that (:) >comes before [] because ... long spiel about branch prediction ... It is the other way round: without branch prediction, the order of tests did matter, branch prediction hardware can figure out many things without help, thereby making the order of tests in the code less important - but that can be defeated. http://en.wikipedia.org/wiki/Branch_prediction As long as you're sure your students don't need to care about performance, there is no need for you to teach them about it. But if their ByteStrings aren't as fast as they need to be, they will very much want to know why (the example in #849 was from ByteString). Unless they just give up. >Controlling branch prediction will only ever be a niche activity, >so the defaults should reflect that. My impression is that branch prediction hardware is (usually) designed for users with full control over generated code (eg, the Intel compiler manuals seem to advise loop unrolling to match and complement the branch prediction hardware exactly). If you don't have that kind of control, and generate code as if there were no hardware-level optimizations, the resulting mismatch will manifest in hard-to-predict variations in performance, making it difficult to see how much or why speed is lost. No fun. Claus From duncan.coutts at worc.ox.ac.uk Wed Mar 25 22:01:50 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 25 21:49:15 2009 Subject: compilation of pattern-matching? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1238032910.25888.26.camel@localhost> On Wed, 2009-03-25 at 09:18 +0000, Simon Peyton-Jones wrote: > * More promising might be to say "this is the hot branch". That information about frequency could in principle be used by the back end to generate better code. However, I am unsure how > a) to express this info in source code > b) retain it throughout optimisation Claus, last time I asked about this approach Simon filed the following ticket: http://hackage.haskell.org/trac/ghc/ticket/849 If you add a new commentary page then it is at least worth cross-referencing this ticket. Duncan From twhitehead at gmail.com Wed Mar 25 22:41:08 2009 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed Mar 25 22:28:49 2009 Subject: compilation of pattern-matching? In-Reply-To: References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <404396ef0903251304y6758adf2i5c10eaf62210eb8f@mail.gmail.com> Message-ID: <200903252241.15414.twhitehead@gmail.com> On March 25, 2009 21:38:55 Claus Reinke wrote: > If you don't have that kind of control, and generate code as if > there were no hardware-level optimizations, the resulting > mismatch will manifest in hard-to-predict variations in > performance, making it difficult to see how much or why > speed is lost. No fun. I would think the ultimate for this would be to be able to feed profiling information into the compiler. No messy pragmas all over the code and I would guess there would be other benefits as well (e.g., inlining decisions). Of course it's easy to sit back and suggest things like this -- but I would image quite a whole other kettle of fish to build them. : ) Cheers! -Tyson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090325/82d64aac/attachment.bin From duncan.coutts at worc.ox.ac.uk Wed Mar 25 22:51:49 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Mar 25 22:39:15 2009 Subject: compilation of pattern-matching? In-Reply-To: <68D4104586604A2090EF7421DF3A6730@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> Message-ID: <1238035909.25888.75.camel@localhost> On Wed, 2009-03-25 at 18:01 +0000, Claus Reinke wrote: > With the hint about branch prediction, I also found this old ticket > (which seems to have been waiting for the new backend, and > indicates rather larger performance differences): > > Offer control over branch prediction > http://hackage.haskell.org/trac/ghc/ticket/849 Oh, I should have read the whole thread first. I see you found it already. Yes, I did find that in the ByteString stream/unstream functions that essentially arbitrary changes in the logic of branches changed performance by a factor of two or so. At the time I put it down to basic block ordering and branch prediction. A related issue is that we cannot reliably force a call to be out-of-line (so it doesn't add code to the hot-path) without also disabling the worker wrapper transform. > But UNLIKELY only covers the most common case > (marking alternatives with minimal expected frequency) - > if clause ordering was respected, relative frequencies of > alternatives could be specified without pragmas, just by > ordering pattern-match or conditional clauses according > to expected frequency. I think marking expectations (either manually or by profile-directed feedback) is a more profitable approach. We can end up with nested cases part way through optimisation that were never there explicitly in the source, so preserving source order is meaningless there. For example consider a simple tail recursive loop: length :: ByteString -> Int length = go 0 where go !n bs | null bs = n | otherwise = go (n+1) (tail bs) There are no explicit cases here. There is nothing for the programmer to order. In any case, this is a user-defined function and they don't know the details of how to optimise this. After inlining we actually find that there are three cases: * the lazy ByteString being Empty * it being a non-empty Chunk with 1 byte left it * it being a non-empty Chunk with more than 1 byte left In similar situations it may be profitable to re-nest the cases. But if we attach likelihoods then that seems more robust than trying to maintain orderings on cases. In the above example I'd annotate the definition of tail to indicate that the chunk being length 1 is not nearly as likely as it not being so. Actually in this example the information probably doesn't need to be given explicitly at all since one branch leads to a recursive call and the other to a function return. A static model here would be enough, no hints or profile feedback required. Duncan From marlowsd at gmail.com Thu Mar 26 04:58:14 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Mar 26 04:45:49 2009 Subject: compilation of pattern-matching? In-Reply-To: References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> Message-ID: <49CB43A6.5050801@gmail.com> Lennart Augustsson wrote: > When you tried switching Nil and Cons, did you try it on many examples? > For a single example a 2-3% could be easily attributed to random > effects like different instruction cache hit patterns. If you get it > consistently over several programs then it seems likely to mean > something, but I'm not sure what. I've seen cases where simply inserting a couple of nops in a hot function improved performance by a significant margin (>10%, IIRC). The only theory I could come up with was that there were more branches in a cache line than the branch prediction cache on this processor could cope with. I don't think it was merely an alignment issue. Cheers, Simon > On Wed, Mar 25, 2009 at 6:01 PM, Claus Reinke wrote: >>> Indeed GHC does not attempt to retain the order of alternatives, although >>> a) it might be possible to do so by paying more attention in numerous >>> places >>> b) GHC may do so already, by accident, in certain cases >> That adds even more unpredictability. One thing that I don't want whenever I >> have to care about performance is small changes >> having odd/unexplainable effects (I vaguely recall a case where removing an >> unused parameter from a recursion made the program >> slower, or eliminating returned constructors by using continuations >> made one inner-loop function faster, another slower..). >> Lennart is of course right: even if GHC would respect the ordering indicated >> in my source program, I might not be able to tune that source to make good >> use of even a single target processor (I tried defining a foldl over a >> user-defined List type, so that I could switch >> the order of Nil/Cons, and hence the test order used by GHC, and found the >> Nil-before-Cons order to be 2-3% faster for folding a >> very long list than the Cons-before-Nil order I wanted), but it is very >> frustrating if I'm not even given the chance because GHC >> sorts the alternatives, not even according to its own interpretation >> of branching performance, but completely arbitrarily!-) >> >>> * The issue at stake is a small one: not the *number of tests* but *which >>> tests branch, and which fall through*. >> Right on the issue, but I'm not quite sure how small it is: the test >> case source I attached a few messages ago consistently showed one ordering >> to be 5% faster than the other for the extreme case >> of one test nearly always failing. There may well be more profitable >> optimizations remaining to be implemented first - what disturbs me is that >> Haskell code is full of conditionals and matches, which I tend to arrange >> according to expected frequency, and GHC simply ignores all those hints. >> >> With the hint about branch prediction, I also found this old ticket (which >> seems to have been waiting for the new backend, and >> indicates rather larger performance differences): >> >> Offer control over branch prediction >> http://hackage.haskell.org/trac/ghc/ticket/849 >> >>> * Simply ordering the equations doesn't really work, because pattern-match >>> compilation will match an entire column at once: >>> f (x:xs) True = ... >>> f [] True = ... >>> f [] False = ... >>> f (x:xs) False = ... >>> Which "order" should the (:)/[] test go in? >> In the order indicated in the source!? The usual pattern-match >> optimizations should not change that, they will just skip the two >> '[]' cases if the list isn't empty, or use the constructor tag to jump >> directly to a sub-column. Haskell specifies left-to-right, top-down. >> >>> * Not only does GHC currently not attempt to retain order, but for a >>> particular order it makes no guarantees about which falls through. For >>> example, given >>> case ... of { A -> e1; C -> e2; B -> e3 } >>> We might test for A and then >>> either fall though to e1 >>> or fall through to the test for C >> That is the part I missed, and which might give the UNLIKELY >> pragma, as suggested in #849, more expressive power than >> plain clause ordering. However, since Haskell specifies a match >> order, I don't see why that couldn't be used as the basis for >> mapping to branches as well, with the clauses listed in decreasing >> likelyhood, and GHC generating the branch predictions and fallthroughs to >> match this information to the target processor characteristics? >> >>> * When the number of constructors is larger, instead of a linear sequence >>> of tests, GHC may generate a table-jump; or a balanced tree of tests. >> The table-jump would make all alternatives equally costly/fast, >> with no penalty for adding infrequent alternatives, right? The >> balanced tree sounds like one of the pattern-match state machines, and there >> would still be room for representing expected frequency in terms of >> tree-path/-rotation/-representation. >> >>> * Which plan performs best is tremendously architecture dependent, and may >>> well vary a lot between different chips implementing the same instruction >>> set. It's a losing battle to fix the strategy in source code. >>> * More promising might be to say "this is the hot branch". That >>> information about frequency could in principle be used by the back end to >>> generate better code. However, I am unsure how >>> a) to express this info in source code >>> b) retain it throughout optimisation >> >> So it should be specified in the source, after all, just in a way >> that gives programmers room to express their knowledge while >> leaving GHC free to implement that knowledge on the target. >> >> Things like the UNLIKELY pragma would seem useful, if >> attached to decisions: unless GHC can optimize the whole decision away, it >> will remain throughout optimization, and come out as some form of branch, >> with the hint still attached. >> >> But UNLIKELY only covers the most common case >> (marking alternatives with minimal expected frequency) - >> if clause ordering was respected, relative frequencies of >> alternatives could be specified without pragmas, just by >> ordering pattern-match or conditional clauses according >> to expected frequency. >> >>> Claus, if you think this thread is worth capturing, then do write a >>> Commentary page, and I'll check its veracity. >> Given the existence of #849, I've just linked this thread >> from there. >> >> Claus >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From marlowsd at gmail.com Thu Mar 26 05:09:39 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Mar 26 04:57:15 2009 Subject: compilation of pattern-matching? In-Reply-To: References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <49CB4653.5040709@gmail.com> Claus Reinke wrote: > Strange. I don't think it is my idea (older implementations > used to work that way, and iirc, it also matches what Prolog > systems used to do), and I didn't think it was anything but > straightforward to avoid case transformations unless there > is a clear benefit, so I doubt there is a useful paper in there > (also, I can't afford to plan that far ahead atm). > What is the benefit of changing the ordering (not just joining paths to > avoid redundant tests, but actually modifying the order of tests, to > sort by their order in the data type declaration)? Is there any > documentation of these case transformations that I could look up? It's not that GHC deliberately re-orders case alternatives, it's that it doesn't deliberately not do it. That's quite an important difference. To check whether case alternatives ever get reordered, we'd have to look at the whole compiler. It's a new constraint on which transformations are valid, and global constraints should not be added lightly. I some kind of annotation is a much more promising avenue to explore. Cheers, Simon From devonrtucker at gmail.com Thu Mar 26 06:44:40 2009 From: devonrtucker at gmail.com (Devon Tucker) Date: Thu Mar 26 06:32:09 2009 Subject: Can't get editline support to work in 6.10.1 Message-ID: <397049c50903260344p44e6204fv27917368f5373a3d@mail.gmail.com> Hello, I recently compiled and installed GHC 6.10.1 on Ubuntu 8.10 64-bit, after having installed 6.8 from the repositories. However when I launched ghci I discovered that the arrow keys and backspace did not work! After some quick googling I came to the conclusion that editline support was not enabled. I installed any package I could find named libedit*-dev and configured and compiled GHC again. Still no luck. Looking at my configure output I see a line like this (paraphrased, I don't have the output in front of me right now): Checking for ghc editline package... no. I really don't know what to do now. I have installed 6.10.1 on almost identical setups without any problem and I find ghci to be totally unproductive without command history and tab-completion. Any help would be greatly appreciated. Cheers, Devon Tucker From igloo at earth.li Thu Mar 26 08:32:23 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 26 08:19:53 2009 Subject: Can't get editline support to work in 6.10.1 In-Reply-To: <397049c50903260344p44e6204fv27917368f5373a3d@mail.gmail.com> References: <397049c50903260344p44e6204fv27917368f5373a3d@mail.gmail.com> Message-ID: <20090326123223.GA32006@matrix.chaos.earth.li> Hi Devon, On Thu, Mar 26, 2009 at 08:14:40AM -0230, Devon Tucker wrote: > > I recently compiled and installed GHC 6.10.1 on Ubuntu 8.10 64-bit, > after having installed 6.8 from the repositories. However when I > launched ghci I discovered that the arrow keys and backspace did not > work! After some quick googling I came to the conclusion that editline > support was not enabled. I installed any package I could find named > libedit*-dev and configured and compiled GHC again. On Debian, libedit-dev is what you want, so I assume the same is true for Ubuntu. > Checking for ghc editline package... no. That's not important; search for Configuring editline in the build log and see what comes after that. Thanks Ian From lennart at augustsson.net Thu Mar 26 09:23:40 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Mar 26 09:11:09 2009 Subject: compilation of pattern-matching? In-Reply-To: <49CB4653.5040709@gmail.com> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <49CB4653.5040709@gmail.com> Message-ID: I find this "reordering" discussion somewhat nonsensical. Haskell specifies top-to-botton, left-to-right matching. This specifies exactly which tests that have to be made and in what order, and ghc does exactly those and in the correct order. One can have a perception that when there are multiple arms in a case decided by a single test, then the first arm should somehow be reached quicker than the second one etc But that is something that the Haskell standard has never promised, nor has any compiler ever promised this. And to me such a perception is counter-intuitive; Haskell is about specifying functions abstractly so order should only matter when it's a matter of semantics. On the other hand, adding some kind of pragma that indicates the likelyhood of a branch seems quite sensible to me. -- Lennart On Thu, Mar 26, 2009 at 9:09 AM, Simon Marlow wrote: > Claus Reinke wrote: > >> Strange. I don't think it is my idea (older implementations >> used to work that way, and iirc, it also matches what Prolog >> systems used to do), and I didn't think it was anything but >> straightforward to avoid case transformations unless there >> is a clear benefit, so I doubt there is a useful paper in there >> (also, I can't afford to plan that far ahead atm). >> What is the benefit of changing the ordering (not just joining paths to >> avoid redundant tests, but actually modifying the order of tests, to sort by >> their order in the data type declaration)? Is there any documentation of >> these case transformations that I could look up? > > It's not that GHC deliberately re-orders case alternatives, it's that it > doesn't deliberately not do it. > > That's quite an important difference. ?To check whether case alternatives > ever get reordered, we'd have to look at the whole compiler. ?It's a new > constraint on which transformations are valid, and global constraints should > not be added lightly. ?I some kind of annotation is a much more promising > avenue to explore. > > Cheers, > ? ? ? ?Simon > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From igloo at earth.li Thu Mar 26 10:09:43 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 26 09:57:13 2009 Subject: Problem with a second installed version of the syb package In-Reply-To: <52f14b210903250743i26c945b1n63a7457195304b78@mail.gmail.com> References: <52f14b210903200133w43152ab0rcf8bd78eb964d111@mail.gmail.com> <20090320233930.GA8825@matrix.chaos.earth.li> <52f14b210903230253p120a50c6v826cc59bcc635363@mail.gmail.com> <20090325125852.GA10162@matrix.chaos.earth.li> <52f14b210903250743i26c945b1n63a7457195304b78@mail.gmail.com> Message-ID: <20090326140943.GA15054@matrix.chaos.earth.li> Hi Pedro, On Wed, Mar 25, 2009 at 03:43:42PM +0100, Jos? Pedro Magalh?es wrote: > > 2009/3/25 Ian Lynagh > > > ghc-options: -package-name syb > > Yes, that works, thanks. I thought this problem was caused by having the syb > package unversioned in the GHC repo, and I also thought that that had > changed, but now I see that the flag -package-name syb is still there. Would > you know if this necessary for some reason? Ah, I guess this was only needed because Data.Data was in syb. I can't see a reason why syb needs to be wired in any more, so I have unwired it in the HEAD. Thanks Ian From marlowsd at gmail.com Thu Mar 26 10:40:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Mar 26 10:28:29 2009 Subject: compilation of pattern-matching? In-Reply-To: References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <49CB4653.5040709@gmail.com> Message-ID: <49CB93F6.7070000@gmail.com> Lennart Augustsson wrote: > I find this "reordering" discussion somewhat nonsensical. > Haskell specifies top-to-botton, left-to-right matching. > This specifies exactly which tests that have to be made and in what order, > and ghc does exactly those and in the correct order. > > One can have a perception that when there are multiple arms in a case > decided by a single test, > then the first arm should somehow be reached quicker than the second one etc > But that is something that the Haskell standard has never promised, > nor has any compiler ever promised this. > And to me such a perception is counter-intuitive; Haskell is about > specifying functions abstractly so order should only matter when it's > a matter of semantics. > > On the other hand, adding some kind of pragma that indicates the > likelyhood of a branch seems quite sensible to me. I completely agree. I think in an effort to be succinct I may have accidentally given the impression that I thought the ordering of case branches in Core mattered for some reason. I don't think that at all, I was just trying to explain why it would be difficult to make ordering meaningful. Cheers, Simon > -- Lennart > > On Thu, Mar 26, 2009 at 9:09 AM, Simon Marlow wrote: >> Claus Reinke wrote: >> >>> Strange. I don't think it is my idea (older implementations >>> used to work that way, and iirc, it also matches what Prolog >>> systems used to do), and I didn't think it was anything but >>> straightforward to avoid case transformations unless there >>> is a clear benefit, so I doubt there is a useful paper in there >>> (also, I can't afford to plan that far ahead atm). >>> What is the benefit of changing the ordering (not just joining paths to >>> avoid redundant tests, but actually modifying the order of tests, to sort by >>> their order in the data type declaration)? Is there any documentation of >>> these case transformations that I could look up? >> It's not that GHC deliberately re-orders case alternatives, it's that it >> doesn't deliberately not do it. >> >> That's quite an important difference. To check whether case alternatives >> ever get reordered, we'd have to look at the whole compiler. It's a new >> constraint on which transformations are valid, and global constraints should >> not be added lightly. I some kind of annotation is a much more promising >> avenue to explore. >> >> Cheers, >> Simon >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> From claus.reinke at talk21.com Thu Mar 26 13:39:14 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Mar 26 13:26:50 2009 Subject: compilation of pattern-matching? References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <49CB4653.5040709@gmail.com> Message-ID: <592AEDEE9A564387A667909A27BF2DF5@cr3lt> Sorry to be the odd man out - perhaps an example will help to clarify my reading of the language definition. >I find this "reordering" discussion somewhat nonsensical. >Haskell specifies top-to-botton, left-to-right matching. >This specifies exactly which tests that have to be made and in what order, >and ghc does exactly those and in the correct order. > >One can have a perception that when there are multiple arms in a case >decided by a single test, then the first arm should somehow be reached >quicker than the second one etc But that is something that the Haskell >standard has never promised, nor has any compiler ever promised this. When you say "test", which can decide multiple arms in a case, do you mean that, say 'null e' being 'True' implies that matching '[]' against 'e' will succeed while matching '_:_' against 'e' will fail? Because that kind of test is not what the Haskell'98 report talks about. It talks about individual matches of expressions against alternatives, and it does specify precisely in what order these are to be performed, hence which pattern is reached first: A case expression is evaluated by pattern matching the expression e against the individual alternatives. The alternatives are tried sequentially, from top to bottom. Patterns are matched against values. Attempting to match a pattern can have one of three results: it may fail; it may succeed, returning a binding for each variable in the pattern; or it may diverge (i.e. return _|_). Pattern matching proceeds from left to right, .. Nothing abstract about that. So for a function application 'f e', where f [] = True f (_:_) = False the Haskell'98 report specifies that 'e' is first matched against '[]', then (if that fails) against (_:_). So the first pattern is reached/tried before the second. Of course, we can make use of the fact that these two matches are complementary, so we only need one "test" to decide, and if there are further '[]' patterns after the first, we don't have to match them again, but that is all in the realm of optimization, not language definition. The definition explicitly provides room for such optimization, but it still requires conformance to the rules set out in the definition, which include: case e of {p1->e1;p2->e2} = case e of {p1->e1;_->case e of {p2->e2;_->error "No match"}} GHC violates that rule, as we can demonstrate: newtype N = N Int deriving (Show,Eq) instance Num N where fromInteger 0 = error "0" fromInteger 1 = N 0 fromInteger _ = N 1 f x = case x of 1 -> False 0 -> True g x = case x of 1 -> False _ -> case x of 0 -> True _ -> error "No match" main = do print $ g (N 0) print $ f (N 0) -- ghc $ ghc -w -e main PMOrderSpec.hs False : 0 -- hugs Main> main False False One can presumably construct similar examples using 'Data.String.IsString', or using pattern guards, so just fixing the special case of 'Num' is not going to help, but this example seems firmly within Haskell'98. >And to me such a perception is counter-intuitive; Haskell is about >specifying functions abstractly so order should only matter when it's >a matter of semantics. Any semantics should conform to the language definition, right? >On the other hand, adding some kind of pragma that indicates the >likelyhood of a branch seems quite sensible to me. Which doesn't mean that I wouldn't try such a pragma, if it existed. I'm just having difficulties understanding this universal resistance to what seems one of the few unambiguously defined parts of Haskell'98;-) Claus From lennart at augustsson.net Thu Mar 26 14:17:47 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Mar 26 14:05:16 2009 Subject: compilation of pattern-matching? In-Reply-To: <592AEDEE9A564387A667909A27BF2DF5@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <49CB4653.5040709@gmail.com> <592AEDEE9A564387A667909A27BF2DF5@cr3lt> Message-ID: So a first comment on this. I spoke too soon, ghc clearly has a bug here. It shouldn't reorder those matches against literals like that. I suggest you report that bug, because, as you say, it violates the H98 report. But I don't think that bug at all affects the function you had in your original email. -- Lennart On Thu, Mar 26, 2009 at 5:39 PM, Claus Reinke wrote: > Sorry to be the odd man out - perhaps an example will help to > clarify my reading of the language definition. > >> I find this "reordering" discussion somewhat nonsensical. >> Haskell specifies top-to-botton, left-to-right matching. >> This specifies exactly which tests that have to be made and in what order, >> and ghc does exactly those and in the correct order. >> >> One can have a perception that when there are multiple arms in a case >> decided by a single test, then the first arm should somehow be reached >> quicker than the second one etc But that is something that the Haskell >> standard has never promised, nor has any compiler ever promised this. > > When you say "test", which can decide multiple arms in a case, do you > mean that, say 'null e' being 'True' implies that matching '[]' against 'e' > will succeed while matching '_:_' against 'e' will fail? Because that kind > of test is not what the Haskell'98 report talks about. It talks about > individual matches of ?expressions against alternatives, and it does > specify precisely in what order these are to be performed, hence > which pattern is reached first: > > ? A case expression is evaluated by pattern matching the expression e > against the individual alternatives. The alternatives are tried > sequentially, ? from top to bottom. > > ? Patterns are matched against values. Attempting to match a pattern can > have one of three results: it may fail; it may succeed, returning a binding > ? for each variable in the pattern; or it may diverge (i.e. return _|_). > Pattern matching proceeds from left to right, .. > > Nothing abstract about that. So for a function application 'f e', where > > ? f [] = True > ? f (_:_) = False > > the Haskell'98 report specifies that 'e' is first matched against '[]', then > (if that fails) against (_:_). So the first pattern is reached/tried before > the second. Of course, we can make use of the fact that these two > matches are complementary, so we only need one "test" to decide, > and if there are further '[]' patterns after the first, we don't have to > match them again, but that is all in the realm of optimization, not language > definition. > The definition explicitly provides room for such optimization, but it still > requires conformance to the rules set out in the definition, which include: > > ? case e of {p1->e1;p2->e2} = ? case e of {p1->e1;_->case e of > {p2->e2;_->error "No match"}} > > GHC violates that rule, as we can demonstrate: > > ? newtype N = N Int deriving (Show,Eq) > ? ? instance Num N where > ? ? fromInteger 0 = error "0" > ? ? fromInteger 1 = N 0 > ? ? fromInteger _ = N 1 > ? ? f x = case x of > ? ? ? ? ? 1 -> False > ? ? ? ? ? 0 -> True > ? ? g x = case x of > ? ? ? ? ? 1 -> False > ? ? ? ? ? _ -> case x of > ? ? ? ? ? ? ? ? 0 -> True > ? ? ? ? ? ? ? ? _ -> error "No match" > ? ? main = do > ? ? print $ g (N 0) > ? ? print $ f (N 0) > > ? -- ghc > ? $ ghc -w -e main PMOrderSpec.hs > ? False > ? : 0 > > ? -- hugs > ? Main> main > ? False > ? False > > One can presumably construct similar examples using 'Data.String.IsString', > or using pattern guards, so just fixing the special case of 'Num' is not > going > to help, but this example seems firmly within Haskell'98. > >> And to me such a perception is counter-intuitive; Haskell is about >> specifying functions abstractly so order should only matter when it's >> a matter of semantics. > > Any semantics should conform to the language definition, right? > >> On the other hand, adding some kind of pragma that indicates the >> likelyhood of a branch seems quite sensible to me. > > Which doesn't mean that I wouldn't try such a pragma, if it existed. > I'm just having difficulties understanding this universal resistance to > what seems one of the few unambiguously defined parts of Haskell'98;-) > > Claus > From igloo at earth.li Thu Mar 26 14:23:19 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Mar 26 14:10:55 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 In-Reply-To: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> References: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> Message-ID: <20090326182319.GA19586@matrix.chaos.earth.li> On Wed, Mar 18, 2009 at 06:51:31AM -0400, Gregory Wright wrote: > > Unexpected failures: > 2469(ghci) This is http://hackage.haskell.org/trac/ghc/ticket/2789 (which is fixed in the new build system). > apirecomp001(normal) This is failing because of "ld: atom sorting error for ..." on OS X http://hackage.haskell.org/trac/ghc/ticket/2578 (I'd love for someone to fix that). > bits > genUpTo These are fixed. > num009 > num012 These still need to be fixed, but I'm pretty sure they aren't regressions. Thanks Ian From jason.dusek at gmail.com Thu Mar 26 19:29:47 2009 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu Mar 26 19:17:15 2009 Subject: Really bad code for single method dictionaries? Message-ID: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> I was reading the stream fusion code today and came across a comment stating that single element dictionaries interacted poorly with GHC's optimizer: class Unlifted a where [...] expose [...] -- | This makes GHC's optimiser happier; it sometimes produces really bad -- code for single-method dictionaries -- unlifted_dummy [...] A cursory search on GHC's Trac shows no corresponding bug; is this no longer a problem? A small problem? I would like to know more about it. -- Jason Dusek |...stream fusion code...| http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs From ndmitchell at gmail.com Thu Mar 26 19:48:45 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Mar 26 19:36:12 2009 Subject: Really bad code for single method dictionaries? In-Reply-To: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> References: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> Message-ID: <404396ef0903261648t1456abd0wec1bb3d1ee84e144@mail.gmail.com> Hi Jason, While experimenting with Uniplate I found that 1-member dictionaries were faster than N element dictionaries - which seems to run against what you see in the comment. 1-member dictionaries being cheaper does make sense as then instead of passing a tuple containing functions, you can pass the direct function, and save yourself a (cheap) selector call at every use. Thanks Neil On Thu, Mar 26, 2009 at 11:29 PM, Jason Dusek wrote: > ?I was reading the stream fusion code today and came across a comment stating > ?that single element dictionaries interacted poorly with GHC's optimizer: > > ? ?class Unlifted a where > > ? ? ?[...] > ? ? ?expose [...] > > ? ? ?-- | This makes GHC's optimiser happier; it sometimes produces really bad > ? ? ?-- code for single-method dictionaries > ? ? ?-- > ? ? ?unlifted_dummy [...] > > ?A cursory search on GHC's Trac shows no corresponding bug; is this no longer > ?a problem? A small problem? I would like to know more about it. > > -- > Jason Dusek > > > > ?|...stream fusion code...| > ?http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From claus.reinke at talk21.com Thu Mar 26 20:10:19 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Mar 26 19:57:51 2009 Subject: compilation of pattern-matching? References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <49CB4653.5040709@gmail.com><592AEDEE9A564387A667909A27BF2DF5@cr3lt> Message-ID: <57646213ECAA471FBAAF39375E5A2FD2@cr3lt> >So a first comment on this. I spoke too soon, ghc clearly has a bug here. >It shouldn't reorder those matches against literals like that. >I suggest you report that bug, because, as you say, it violates the H98 report. It would be nice if we could first reach a common understanding, so that I can actually report the right problem, not just isolated symptoms. >But I don't think that bug at all affects the function you had in your >original email. The argument goes like this: - Haskell does prescribe the order in which patterns are matched - Haskell does permit alternative implementations if they respect certain equations; in other words, there is a proof obligation associated with things like reordering patterns - for types like 'data AB = A | B', we know that a successful match for 'A' implies a failing match for 'B', and vice-versa - disregarding performance (which the language definition does not talk about), we therefore know that in 'case e of A->a;B->b', we don't need to match for both 'A' and 'B'; instead, we can either match for 'A' and enter 'a' on success and 'b' on failure, or match for 'B' and enter 'b' on success and 'a' on failure - another view of this is that 'not isB' is actually the same as 'isA', so we're matching for both in one test - so, if we want to, we can fulfill the proof obligation involved with reordering the patterns, or we can argue that by matching for 'B', we are actually matching for 'A' as well So far, we have: - pattern order does matter, by language definition - GHC can nevertheless reorder patterns where it can prove that this isn't observable You are right that this doesn't help my performance argument, as performance issues are outside the language definition (not observable in the language definition sense). It was merely an answer to the vehement claims that pattern order is irrelevant. And it has practical implications, too: the proof obligations are getting harder to fulfill as pattern-match expressiveness improves. For Haskell'98, we can't reorder: guards, overlapping patterns, numeric literals, (others?). For GHC Haskell, we also can't reorder: view patterns, string literals (IsString/fromString), quasiquotes?, .. . And the list keeps growing, as DSL authors want IsBool/fromBool, container-library authors want IsList/fromList, etc. In other words, this |It's not that GHC deliberately re-orders case alternatives, |it's that it doesn't deliberately not do it. no longer is a safe default strategy (actually, it never was, as the bug shows;-). Neither is sorting patterns by constructor tag, as seems to happen on the way to Core. GHC needs to consider every individual case before being lax about pattern order, and the result of that consideration might change over time: in Haskell'98, []/: patterns can be reordered for [a], in GHC Haskell, []/:. patterns can be reordered for [a], as long as a/=Char, in GHC Haskell with an IsList class, []/: patterns can not be reordered in general. This is independent of performance considerations, just a consequence of the language definition, and our abilities to observe deviations from the prescribed sequential order. Claus From lennart at augustsson.net Thu Mar 26 21:13:26 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Mar 26 21:00:53 2009 Subject: compilation of pattern-matching? In-Reply-To: <57646213ECAA471FBAAF39375E5A2FD2@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <49CB4653.5040709@gmail.com> <592AEDEE9A564387A667909A27BF2DF5@cr3lt> <57646213ECAA471FBAAF39375E5A2FD2@cr3lt> Message-ID: Sorting by constructor tag is perfectly safe when done right. You can read about how to do it in my 1985 FPCA paper or in Simon's book. When pattern matching against against things that that are not constructors (like literals etc) it's much trickier to reorder them since you have to prove harder pattern commutation properties. I don't think there is any controversy at all about Haskell pattern matching semantics. As you say, it's pretty clearly spelled out. (It wouldn't hurt to have it written down as a denotational semantics, though.) And ghc happens to have a bug. -- Lennart On Fri, Mar 27, 2009 at 12:10 AM, Claus Reinke wrote: >> So a first comment on this. ?I spoke too soon, ghc clearly has a bug here. >> It shouldn't reorder those matches against literals like that. >> I suggest you report that bug, because, as you say, it violates the H98 >> report. > > It would be nice if we could first reach a common understanding, so > that I can actually report the right problem, not just isolated symptoms. > >> But I don't think that bug at all affects the function you had in your >> original email. > > The argument goes like this: > > - Haskell does prescribe the order in which patterns are matched > - Haskell does permit alternative implementations if they respect > ? certain equations; in other words, there is a proof obligation > ? associated with things like reordering patterns > - for types like 'data AB = A | B', we know that a successful match > ? for 'A' implies a failing match for 'B', and vice-versa > - disregarding performance (which the language definition does > ? not talk about), we therefore know that in 'case e of A->a;B->b', > ? we don't need to match for both 'A' and 'B'; instead, we can ? either > match for 'A' and enter 'a' on success and 'b' on failure, > ? or match for 'B' and enter 'b' on success and 'a' on failure > - another view of this is that 'not isB' is actually the same as 'isA', > ? so we're matching for both in one test > - so, if we want to, we can fulfill the proof obligation involved ? with > reordering the patterns, or we can argue that by matching > ? for 'B', we are actually matching for 'A' as well > > So far, we have: > > - pattern order does matter, by language definition > - GHC can nevertheless reorder patterns where it can prove ? that this isn't > observable > > You are right that this doesn't help my performance argument, > as performance issues are outside the language definition (not > observable in the language definition sense). It was merely an answer to the > vehement claims that pattern order is irrelevant. > > And it has practical implications, too: the proof obligations are > getting harder to fulfill as pattern-match expressiveness improves. > > For Haskell'98, we can't reorder: guards, overlapping patterns, > numeric literals, (others?). For GHC Haskell, we also can't reorder: view > patterns, string literals (IsString/fromString), quasiquotes?, .. . And the > list keeps growing, as DSL authors want IsBool/fromBool, container-library > authors want IsList/fromList, etc. > In other words, this > > |It's not that GHC deliberately re-orders case alternatives, |it's that it > doesn't deliberately not do it. > > no longer is a safe default strategy (actually, it never was, as > the bug shows;-). Neither is sorting patterns by constructor tag, > as seems to happen on the way to Core. > > GHC needs to consider every individual case before being lax about pattern > order, and the result of that consideration might change over time: in > Haskell'98, []/: patterns can be reordered for [a], in GHC Haskell, []/:. > patterns can be reordered for [a], as long as a/=Char, in GHC Haskell with > an IsList class, []/: patterns can not be reordered in general. > > This is independent of performance considerations, just a > consequence of the language definition, and our abilities to > observe deviations from the prescribed sequential order. > > Claus > From dons at galois.com Fri Mar 27 03:32:42 2009 From: dons at galois.com (Don Stewart) Date: Fri Mar 27 03:21:11 2009 Subject: Really bad code for single method dictionaries? In-Reply-To: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> References: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> Message-ID: <20090327073241.GA19858@whirlpool.galois.com> I don't think this is still the case. Roman, do you remember? - Don jason.dusek: > I was reading the stream fusion code today and came across a comment stating > that single element dictionaries interacted poorly with GHC's optimizer: > > class Unlifted a where > > [...] > expose [...] > > -- | This makes GHC's optimiser happier; it sometimes produces really bad > -- code for single-method dictionaries > -- > unlifted_dummy [...] > > A cursory search on GHC's Trac shows no corresponding bug; is this no longer > a problem? A small problem? I would like to know more about it. > > -- > Jason Dusek > > > > |...stream fusion code...| > http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Fri Mar 27 04:07:20 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Mar 27 03:55:59 2009 Subject: Really bad code for single method dictionaries? In-Reply-To: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> References: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33507A2437F@EA-EXMSG-C334.europe.corp.microsoft.com> I would like to know more too. No one told me! Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Jason Dusek | Sent: 26 March 2009 23:30 | To: glasgow-haskell-users@haskell.org | Subject: Really bad code for single method dictionaries? | | I was reading the stream fusion code today and came across a comment stating | that single element dictionaries interacted poorly with GHC's optimizer: | | class Unlifted a where | | [...] | expose [...] | | -- | This makes GHC's optimiser happier; it sometimes produces really bad | -- code for single-method dictionaries | -- | unlifted_dummy [...] | | A cursory search on GHC's Trac shows no corresponding bug; is this no longer | a problem? A small problem? I would like to know more about it. | | -- | Jason Dusek | | | | |...stream fusion code...| | http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From rl at cse.unsw.edu.au Fri Mar 27 04:18:17 2009 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Mar 27 04:05:59 2009 Subject: Really bad code for single method dictionaries? In-Reply-To: <20090327073241.GA19858@whirlpool.galois.com> References: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> <20090327073241.GA19858@whirlpool.galois.com> Message-ID: On 27/03/2009, at 18:32, Don Stewart wrote: > I don't think this is still the case. > > Roman, do you remember? Hmm, not really. I recall that there was some sort of problem which I didn't have time to investigate then but it's been so long... Roman From batterseapower at hotmail.com Fri Mar 27 04:18:49 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Fri Mar 27 04:06:15 2009 Subject: Really bad code for single method dictionaries? In-Reply-To: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> References: <42784f260903261629j468100c1w995df2c18e65a0d2@mail.gmail.com> Message-ID: <9d4d38820903270118i32e72a6o566e023627d188a7@mail.gmail.com> 2009/3/26 Jason Dusek : > ?I was reading the stream fusion code today and came across a comment stating > ?that single element dictionaries interacted poorly with GHC's optimizer: > > ? ?class Unlifted a where > > ? ? ?[...] > ? ? ?expose [...] > > ? ? ?-- | This makes GHC's optimiser happier; it sometimes produces really bad > ? ? ?-- code for single-method dictionaries > ? ? ?-- > ? ? ?unlifted_dummy [...] > > ?A cursory search on GHC's Trac shows no corresponding bug; is this no longer > ?a problem? A small problem? I would like to know more about it. I'm not sure if there is a bad interaction with rewrite rules (which I assume was the complaint) but single method dictionaries tend to be faster because they are represented by a coercion in the Core language, which means that packing and unpacking the dictionary is free at runtime. Cheers, Max From simonpj at microsoft.com Fri Mar 27 04:47:39 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Mar 27 04:35:06 2009 Subject: compilation of pattern-matching? In-Reply-To: <57646213ECAA471FBAAF39375E5A2FD2@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft <49CB4653.5040709@gmail.com><592AEDEE9A564387A667909A27BF2DF5@cr3lt> <57646213ECAA471FBAAF39375E5A2FD2@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33507A243DB@EA-EXMSG-C334.europe.corp.microsoft.com> | It would be nice if we could first reach a common understanding, so | that I can actually report the right problem, not just isolated symptoms. It's quite simple. The Reports specifies the semantics, not the operational behaviour. Any implementation that behaves as the Report specifies is OK. > GHC violates that rule, as we can demonstrate: > > newtype N = N Int deriving (Show,Eq) Until this moment I believed that GHC respected the Report, and our discussion related solely to performance. But your diligent persistence has indeed uncovered a bug. Thank you! You deserve an accolade. The problem you have uncovered is this. Consider case (x,y) of (0, 'x') -> ... (1, 'y') -> ... (0, 'p') -> ... Then it's fine for GHC to combine the two tests on 0, thus: case x of 0 -> case y of ... 1 -> case y of ... But in doing the *combining* I also allowed the two to be *re-ordered*. That is fine for data constructors, and it's fine if 'fromInteger' is injective, but it is NOT fine in general. Thank you for finding this. I'll fix it. And in fixing it I may as well arrange not to re-order constructors too, which will make you happier. Happier, not happy, because I make no guarantees of what may happen downstream! thanks Claus. Since you discovered it, would you like to have the dubious honour of opening a Trac report, which I'll then fix? Simon From marlowsd at gmail.com Fri Mar 27 04:57:50 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Mar 27 04:45:24 2009 Subject: compilation of pattern-matching? In-Reply-To: References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com> <68D4104586604A2090EF7421DF3A6730@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <49CB4653.5040709@gmail.com> <592AEDEE9A564387A667909A27BF2DF5@cr3lt> <57646213ECAA471FBAAF39375E5A2FD2@cr3lt> Message-ID: <49CC950E.9050108@gmail.com> Lennart Augustsson wrote: > Sorting by constructor tag is perfectly safe when done right. > You can read about how to do it in my 1985 FPCA paper or in Simon's book. > > When pattern matching against against things that that are not > constructors (like literals etc) it's much trickier to reorder them > since you have to prove harder pattern commutation properties. > > I don't think there is any controversy at all about Haskell pattern > matching semantics. > As you say, it's pretty clearly spelled out. > (It wouldn't hurt to have it written down as a denotational semantics, though.) > > And ghc happens to have a bug. Just thought I'd mention this other bug in the same area: http://hackage.haskell.org/trac/ghc/ticket/246 (Wrong pat-match order for records) Cheers, Simon From marlowsd at gmail.com Fri Mar 27 05:14:42 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Mar 27 05:02:17 2009 Subject: compilation of pattern-matching? In-Reply-To: <57646213ECAA471FBAAF39375E5A2FD2@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <49CB4653.5040709@gmail.com><592AEDEE9A564387A667909A27BF2DF5@cr3lt> <57646213ECAA471FBAAF39375E5A2FD2@cr3lt> Message-ID: <49CC9902.9030408@gmail.com> Claus Reinke wrote: > You are right that this doesn't help my performance argument, > as performance issues are outside the language definition (not > observable in the language definition sense). It was merely an answer to > the vehement claims that pattern order is irrelevant. The order of branches in a case expression *in Core* is irrelevant (except that GHC assumes DEFAULT comes first). The order of pattern matches in a Haskell expression is, of course, semantically significant. Nobody is claiming you can change the order of pattern matches in Haskell in general without it changing the meaning. > |It's not that GHC deliberately re-orders case alternatives, |it's that > it doesn't deliberately not do it. > > no longer is a safe default strategy (actually, it never was, as > the bug shows;-). Neither is sorting patterns by constructor tag, > as seems to happen on the way to Core. I was talking about Core. I thought you were too - sorry. Since what you wanted was the order of tests to somehow remain fixed from Haskell through to assembly code, that would imply not reordering them through Core, which GHC does not guarantee not to do. The order of branches in a case expression has no semantic significance in Core. Cheers, Simon PS. nice bug. From claus.reinke at talk21.com Fri Mar 27 06:46:46 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Mar 27 06:34:18 2009 Subject: compilation of pattern-matching? References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoft.com> <49CB4653.5040709@gmail.com><592AEDEE9A564387A667909A27BF2DF5@cr3lt><57646213ECAA471FBAAF39375E5A2FD2@cr3lt> Message-ID: <0B56A3FA31A74881856287C2FE358D61@cr3lt> Ticket is http://hackage.haskell.org/trac/ghc/ticket/3126 . >Sorting by constructor tag is perfectly safe when done right. >You can read about how to do it in my 1985 FPCA paper or in Simon's book. I did, long ago. I learned functional programming by implementing a small functional language, using the Kiel Reduction Language (remember that one? It not only took programming with functions to a level not yet available with modern implementations, it also had a pattern-match sublanguage and engine that was as complex as the rest of it taken together, so we were encouraged to read up on pattern matching in general), C, and your papers. Which made this discussion interesting, as I'm easily intimidated by strongly expressed opinions from people who wrote about this stuff when I was still learning about it;-) >When pattern matching against against things that that are not >constructors (like literals etc) it's much trickier to reorder them >since you have to prove harder pattern commutation properties. Good that we now seem to agree on things. Simon: there aren't really any patterns to combine in the test case, so I assume the reordering happens when "combining" a single pattern? Fill the fix you envisioned also cover the IsString variant? Claus From marlowsd at gmail.com Fri Mar 27 08:47:56 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Mar 27 08:35:27 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 In-Reply-To: <20090326182319.GA19586@matrix.chaos.earth.li> References: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> <20090326182319.GA19586@matrix.chaos.earth.li> Message-ID: <49CCCAFC.903@gmail.com> Ian Lynagh wrote: > On Wed, Mar 18, 2009 at 06:51:31AM -0400, Gregory Wright wrote: >> Unexpected failures: >> 2469(ghci) > > This is > http://hackage.haskell.org/trac/ghc/ticket/2789 > (which is fixed in the new build system). > >> apirecomp001(normal) > > This is failing because of > "ld: atom sorting error for ..." on OS X > http://hackage.haskell.org/trac/ghc/ticket/2578 > (I'd love for someone to fix that). > >> bits >> genUpTo > > These are fixed. > >> num009 >> num012 > > These still need to be fixed, but I'm pretty sure they aren't > regressions. I have a fix for num012 (the test is broken), but I still don't know what's going on with num009. Cheers, Simon From simonpj at microsoft.com Fri Mar 27 08:48:47 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Mar 27 08:36:40 2009 Subject: compilation of pattern-matching? In-Reply-To: <0B56A3FA31A74881856287C2FE358D61@cr3lt> References: <90F4CFDBFEE64E288BA3B948C404B78E@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBCEBF17@EA-EXMSG-C334.europe.corp.microsoft.com><68D4104586604A2090EF7421DF3A6730@cr3lt><638ABD0A29C8884A91BC5FB5C349B1C334CBD8DBB3@EA-EXMSG-C334.europe.corp.microsoftAF39375E5A2FD2@cr3lt> <0B56A3FA31A74881856287C2FE358D61@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33507A24627@EA-EXMSG-C334.europe.corp.microsoft.com> | Simon: there aren't really any patterns to combine in the test case, | so I assume the reordering happens when "combining" a single | pattern? Fill the fix you envisioned also cover the IsString variant? yes it will. S From batterseapower at hotmail.com Fri Mar 27 09:21:25 2009 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Fri Mar 27 09:08:53 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 In-Reply-To: <49CCCAFC.903@gmail.com> References: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> <20090326182319.GA19586@matrix.chaos.earth.li> <49CCCAFC.903@gmail.com> Message-ID: <9d4d38820903270621w696b3b2bm47b80d48c012312@mail.gmail.com> 2009/3/27 Simon Marlow : > I have a fix for num012 (the test is broken), but I still don't know what's > going on with num009. num009 has been broken on OS X for as long as I can remember :-). I opened a ticket about it on Trac way back: http://hackage.haskell.org/trac/ghc/ticket/2370 (not that that ticket has any useful information in it...) Cheers, Max From Malcolm.Wallace at cs.york.ac.uk Fri Mar 27 10:07:22 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Mar 27 09:56:47 2009 Subject: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1 In-Reply-To: <9d4d38820903270621w696b3b2bm47b80d48c012312@mail.gmail.com> References: <149E9119-4BBF-4845-B975-31FA449FEA4C@comcast.net> <20090326182319.GA19586@matrix.chaos.earth.li> <49CCCAFC.903@gmail.com> <9d4d38820903270621w696b3b2bm47b80d48c012312@mail.gmail.com> Message-ID: <20090327140722.4d1143cc.Malcolm.Wallace@cs.york.ac.uk> Max Bolingbroke wrote: > 2009/3/27 Simon Marlow : > > I have a fix for num012 (the test is broken), but I still don't know > > what's going on with num009. > > num009 has been broken on OS X for as long as I can remember :-). If it is any help, I can confirm that num009 works correctly on a PowerPC Mac with both ghc-6.8.2 and 6.10.1, but it fails on an Intel Mac at least as far back as ghc-6.8.3. Regards, Malcolm From marcot at holoscopio.com Fri Mar 27 11:14:49 2009 From: marcot at holoscopio.com (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Fri Mar 27 11:02:22 2009 Subject: Int vs Word performance? Message-ID: <1238166889.3964.170.camel@zezinho> Hello, sorry for breaking the thread, I just got in the list. Simon Peyton-Jones simonpj at microsoft.com : > PS: in the case that no one gets around to creating such a patch, > creating a ticket that documents the problem and points to the needed > specialisations would be a start Was this created? I could not find something about it in the GHC trac. Greetings. -- marcot http://marcot.iaaeee.org/ From claus.reinke at talk21.com Fri Mar 27 12:39:23 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Mar 27 12:26:54 2009 Subject: Int vs Word performance? References: <1238166889.3964.170.camel@zezinho> Message-ID: <067EDB1F47994A1BA5960EA184335233@cr3lt> > Simon Peyton-Jones simonpj at microsoft.com : >> PS: in the case that no one gets around to creating such a patch, >> creating a ticket that documents the problem and points to the needed >> specialisations would be a start > > Was this created? I could not find something about it in the GHC trac. Yes: http://hackage.haskell.org/trac/ghc/ticket/3055 > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Does anyone know why this mailing list archive loses thread links when they cross month boundaries? That is rather inconvenient for catching up with old threads or providing links to information in them (from tickets, etc.). Claus From claus.reinke at talk21.com Fri Mar 27 17:32:13 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Mar 27 17:19:43 2009 Subject: Loop unrolling + fusion ? References: <20090228174932.GA23519@whirlpool.galois.com><26F191DA11EA4B16A6B2E9AAF1DA93B4@cr3lt><9d4d38820903010932m622b80c7lfaca952e0a724a28@mail.gmail.com><35DD9685B0814863B1379F2995C81F8C@cr3lt><9d4d38820903011431g77cc2fcaqafd92d4643019bdd@mail.gmail.com><1064B0BBEFC04EC880CDB86288D0360D@cr3lt> <9d4d38820903190206w1dfa820byb5349810844e3f3d@mail.gmail.com> Message-ID: <4354F4359BAF43839AEC136C4F49D387@cr3lt> > I can't see any issues with this version of the spec. Thanks. From the silence, we seemed to have lost the innocent bystanders? Anyway, for those who haven't noticed, there is now a feature request ticket (for that good feeling of closing it when this is finally implemented;-) as well as a wiki page describing the issues, spec, and examples: http://hackage.haskell.org/trac/ghc/ticket/3123 http://hackage.haskell.org/trac/ghc/wiki/Inlining > I think in the implementation it makes most sense to do this as a > core2core pass at an early stage in the pipeline, probably via plugins > (so will have to wait until I get those into HEAD). What are the plans for plugin support? I do think plugins will be useful, but inlining is pretty central to the existing optimizer transformations, isn't it? Would the transformation code differ much between in-GHC and via-plugins? Perhaps the transformation pass could be implemented now, and later moved out into a plugin, possibly along with other passes. I have also been wondering about the relation between rewrite RULES and plugins. Assuming we can find a more convenient syntax, aren't plugin+syb-based rewrites going to be more expressive, with more control than RULES? Or is the syntactic/compiletime overhead going to remain so high that both RULES and plugins will be kept in GHC? (cf the recent thread on "optimization and rewrite rules questions" http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016702.html ) >In the case of > PEEL, we don't want to identify all call sites directly and do the > substitution in the pass so we should just output some bindings which > will certainly be inlined into call sites later on. So, the > transformation should be bottom up on the Core syntax tree and when it > meets a recursive group of bindings we should do something like this: > > {-# INLINE f g PEEL 3 UNROLL 2 #-} > f = ... g ... f ... h ... > g = ... g ... f ... h ... > h = ... g ... f ... h ... > > =(my pass)=> > > -- Temporary copies of f and g - dead code > f_old = ... g_old ... f_old ... h ... > g_old = ... g_old ... f_old ... h ... > -- H unchanged for now, might get PEELed stuff inlined later > h = ... g .. f ... h ... You mean UNROLLed stuff (PEEL is only for entries into the group). > -- Top level unrolled definiiton - if we weren't doing peeling, these > would be the new f and g > f_unrolled = ... g_unrolled_1 ... f_unrolled_1 ... h ... > g_unrolled = ... g_unrolled_1 ... f_unrolled_1 ... h ... > > -- Unrolled iteration. Will get inlined into f_unrolled / g_unrolled soon > {-# INLINE f_unrolled_1 g_unrolled_1 #-} > f_unrolled_1 = ... g_unrolled ... f_unrolled ... h ... > g_unrolled_1 = ... g_unrolled ... f_unrolled ... h ... Ah, yes, we need to be unambiguous about the interpretation of the counters:-) I was thinking of n+1 (adding n copies to the original), you are thinking of n (adding copies until there are n). > -- One level of peeling > {-# INLINE f_1 g_1 #-} > f_1 = ... g_unrolled ... f_unrolled ... h ... > g_1 = ... g_unrolled ... f_unrolled ... h ... > > -- Second level of peeling > {-# INLINE f_2 g_2 #-} > f_2 = ... g_1 ... f_1 ... h ... > g_2 = ... g_1 ... f_1 ... h ... > > -- Final level of peeling and new definitions for f and g. Inline pragmas > -- make sure all of this gets inlined at the call site > {-# INLINE f g #-} > f = ... g_2 ... f_2 ... h ... > g = ... g_2 ... f_2 ... h ... Wait, now you are counting to n+1 for PEEL and to n for UNROLL? > =(after the simplifier has run - effectively - there are a few > harmless lies here)=> > > -- NB: I haven't shown inlining of the new f and g here, but it /will/ happen > h = ... g .. f ... h ... Since we are interpreting recursive groups as single entities, and there is usually no inlining into definitions that will get inlined, we will have to specify this carefully. > -- I've inlined the inner unrolled iteration at every /call site/ > within the top level unrolled iteration, as per > -- the pragmas. Noone actualy calls this unrolled thing directly > though, since we used PEEL as well > f_unrolled = ... (... g_unrolled ... f_unrolled ... h ...) ... (... > g_unrolled ... f_unrolled ... h ...) ... h ... > g_unrolled = ... (... g_unrolled ... f_unrolled ... h ...) ... (... > g_unrolled ... f_unrolled ... h ...) ... h ... Again, we have to make sure of this interpretation. > -- This huge chunk of code gets inlined at every call site, which in > turn call through to the unrolled bodies > {-# INLINE f g #-} > f = ... (... (... g_unrolled ... f_unrolled ... h ...) ... (... > g_unrolled ... f_unrolled ... h ...) ... h ...) ... (... (... > g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ... > f_unrolled ... h ...) ... h ...) ... h ... > g = ... (... (... g_unrolled ... f_unrolled ... h ...) ... (... > g_unrolled ... f_unrolled ... h ...) ... h ...) ... (... (... > g_unrolled ... f_unrolled ... h ...) ... (... g_unrolled ... > f_unrolled ... h ...) ... h ...) ... h ... So this would be the result of inlining all the PEEL instances into 'f' and 'g'. > By ensuring that f and g are tagged INLINE we get the existing INLINE > restrictions automatically in later Core passes. So the INLINE gets added after your pass is through, so that it isn't affected, but later passes are. But what if there are multiple such PEEL/ UNROLL definitions handled by the one pass? Since the pass doesn't do general INLINE, that is out of the way, but wouldn't it still PEEL stuff from one group into the definitions from another group, even if those definitions themselves are about to be PEELed/INLINEd? And do we want that or not? > I think that this example transformation matches your spec - am I right? Looks mostly right, apart from the ambiguities I mentioned. Could you please add your implementation sketch to the wiki page? Claus From colin at colina.demon.co.uk Sun Mar 29 10:29:43 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Mar 29 10:17:03 2009 Subject: Unable to compile ghc from darcs Message-ID: I was getting errors somewhere in haddock about some ambiguous function, so I did a darcs pull to see if that would pull in a fix for the problem (unfortunately I didn't make a note of the errors). But now the compile fails earlier with errors in deSugar/DsMeta.hs: deSugar/DsMeta.hs:471:48: Not in scope: type constructor or class `TH.InlineSpecQ' deSugar/DsMeta.hs:504:16: Not in scope: type constructor or class `TH.TyVarBndr' deSugar/DsMeta.hs:538:50: Not in scope: type constructor or class `TH.TyVarBndr' deSugar/DsMeta.hs:640:29: Not in scope: type constructor or class `TH.Kind' etc. Is the code in darcs supposed to be compilable normally? And what can I do about such situations? Just report them here? -- Colin Adams Preston Lancashire From mad.one at gmail.com Sun Mar 29 17:31:11 2009 From: mad.one at gmail.com (Austin Seipp) Date: Sun Mar 29 17:18:33 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: Message-ID: <1238362226-sup-9717@existential.local> Excerpts from Colin Paul Adams's message of Sun Mar 29 09:29:43 -0500 2009: > I was getting errors somewhere in haddock about some ambiguous > function, so I did a darcs pull to see if that would pull in a fix for > the problem (unfortunately I didn't make a note of the errors). > > But now the compile fails earlier with errors in deSugar/DsMeta.hs: > > deSugar/DsMeta.hs:471:48: > Not in scope: type constructor or class `TH.InlineSpecQ' > > deSugar/DsMeta.hs:504:16: > Not in scope: type constructor or class `TH.TyVarBndr' > > deSugar/DsMeta.hs:538:50: > Not in scope: type constructor or class `TH.TyVarBndr' > > deSugar/DsMeta.hs:640:29: > Not in scope: type constructor or class `TH.Kind' > > etc. > > Is the code in darcs supposed to be compilable normally? > > And what can I do about such situations? Just report them here? Sounds like it has to do with a template haskell update. >From the root of the source tree, do: $ make distclean $ ./darcs-all pull -a Then, $ ./configure ... $ make ... like usual. Austin From divisortheory at gmail.com Sun Mar 29 17:56:08 2009 From: divisortheory at gmail.com (Zachary Turner) Date: Sun Mar 29 17:43:25 2009 Subject: Few problems with building GHC Message-ID: <478231340903291456q320f1256q2750ed4933a25d0f@mail.gmail.com> Hi, This is my first time trying to compile GHC, so forgive me if these issues are mentioned somewhere. I couldn't find them anywhere on the wiki. First, I had originally installed a binary distribution and then tried to compile another program (a Haskell editor) that recommended I have source available for all libraries, since it would be able to give me better info in the editor. So this is why I decided to compile GHC from source in the first place. So I compiled GHC, and did make install, and I was _expecting_ that all of the library sources would end up in the directories alongside the binaries as well and that this is how the editor would be able to locate the source. But this did not happen, and instead my library folders look exactly like they do in the binary distribution that I installed by downloading the prepacked installer from the website. However, at one point I had downloaded some packages from Hackage and installed them with runhaskell configure, runhaskell build, runhaskell install on each of these new libraries, and the source did end up in the library directories alongside the binaries. So I feel like I'm doing something wrong in building GHC, and that when I install there should be a way to have the source of the libraries copied to the target directories. Can someone elaborate on how this is supposed to work for other programs that depend on the library sources to be able to find them? I know that of the 2 Hackage packages that I installed, the editor printed a message saying that it did find source for those two, but not for any other libraries. Second, I cannot create a windows build of GHC under cygwin. Looking at the Building Guide on the wiki suggests that this is indeed supported. However, when I try to build it I get cabal-bin.exe: Cannot find the program 'ghc' at '/cygdrive/c/dev/haskell/ghc/ghc-6.10.1/bin/ghc' or on the path make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/dev/haskell/ghc/ghc-6.10.1-src/libraries' make: *** [stage1] Error 2 There seems to be some unix/windows confusion here, because it's looking for an executable file named "ghc", when the actual executable name is "ghc.exe". However, building under MSYS everything works perfectly. Is Cygwin just not supported, or do I need to change something here? I don't see any point in cluttering up my system with tons of extra software like MinGW, msys, etc if Cygwin works fine. Last, after building GHC when I go to run make install, I want the target location to be the original location of the compiler that I used to build GHC in the beginning. In other words, I want to have it overwrite the old version of GHC instead of going to the default install location under /usr/bin, etc... How can I specify the target install location? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090329/36a901e9/attachment.htm From claus.reinke at talk21.com Sun Mar 29 18:35:24 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Mar 29 18:22:47 2009 Subject: Few problems with building GHC References: <478231340903291456q320f1256q2750ed4933a25d0f@mail.gmail.com> Message-ID: I was going to suggest following the source links in the Haddock pages, until I saw your motivation: > First, I had originally installed a binary distribution and then tried to > compile another program (a Haskell editor) that recommended I have source > available for all libraries, since it would be able to give me better info > in the editor. That is a typical problem for source-based programming tools in a ghc/cabal-based programming environment. I'm not aware of a standardized solution yet. Some tools get away with the information the GHC Api provides about compiled packages, eg editors/IDEs usually only need the types and haddocks of the exported identifiers; some tools require their own additional info to be built for each package, eg profiling/ haddock; some tools would really like to get access to the source for installed packages, eg program transformation tools that want to unfold definitions across package boundaries. Getting the source that actually matches the installed binaries is not straightforward (unrecorded compilation options). Sometimes, one "accurate in spirit" version of the source might be sufficient independent of the details of the installed binary packages. There are tickets pending, with discussion of the issues: http://hackage.haskell.org/trac/ghc/ticket/2630 http://hackage.haskell.org/trac/hackage/ticket/364 Also, Cabal has recently acquired an 'unpack' command, which allows to unpack the source for a package into a local directory. But someone still needs to connect the pieces, either for each tool, or for a common framework that all source-dependent tools could use. > Second, I cannot create a windows build of GHC under cygwin. Looking > at the Building Guide on the wiki suggests that this is indeed supported. Personally, I last built the head version $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.11.20090320 that way. The buildbots seem to succeed most of the time recently, with some recent issues in stable: http://darcs.haskell.org/buildbot/ (whenever windows head/stable builds there, it is a good time to pull patches;-) > However, when I try to build it I get > > cabal-bin.exe: Cannot find the program 'ghc' at > '/cygdrive/c/dev/haskell/ghc/ghc-6.10.1/bin/ghc' or on the path > make[1]: *** [bootstrapping.conf] Error 1 > make[1]: Leaving directory > `/cygdrive/c/dev/haskell/ghc/ghc-6.10.1-src/libraries' > make: *** [stage1] Error 2 > > There seems to be some unix/windows confusion here, because it's looking for > an executable file named "ghc", when the actual executable name is > "ghc.exe". Not just that. Cabal is also trying to find ghc via a cygwin path (about which ghc-compiled binaries like Cabal don't know a thing). Are you sure you've configured for mingw? Otherwise the build system will try to proceed in cygwin, as if for a unix platform. >However, building under MSYS everything works perfectly. Is > Cygwin just not supported, or do I need to change something here? I don't > see any point in cluttering up my system with tons of extra software like > MinGW, msys, etc if Cygwin works fine. Mingw provides the C compiler, msys or cygwin the build tools. Even under cygwin, you still need to configure to use the mingw C compiler and linker (not the cygwin versions of these). Simon Marlow has recently cleaned up the build instructions http://hackage.haskell.org/trac/ghc/wiki/Building If there's still anything missing or ambiguous in there, please provide details, questions, or improve the wiki pages. We all like those instructions to be accurate, for the next time we start from scratch!-) Claus From divisortheory at gmail.com Sun Mar 29 19:01:11 2009 From: divisortheory at gmail.com (Zachary Turner) Date: Sun Mar 29 18:48:29 2009 Subject: Few problems with building GHC In-Reply-To: References: <478231340903291456q320f1256q2750ed4933a25d0f@mail.gmail.com> Message-ID: <478231340903291601k11519a28r494ec835bb924997@mail.gmail.com> On Sun, Mar 29, 2009 at 5:35 PM, Claus Reinke wrote: > > Getting the source that actually matches the installed binaries is > not straightforward (unrecorded compilation options). Sometimes, > one "accurate in spirit" version of the source might be sufficient > independent of the details of the installed binary packages. There are > tickets pending, with discussion of the issues: > > http://hackage.haskell.org/trac/ghc/ticket/2630 > http://hackage.haskell.org/trac/hackage/ticket/364 > > Also, Cabal has recently acquired an 'unpack' command, which > allows to unpack the source for a package into a local directory. > > But someone still needs to connect the pieces, either for each > tool, or for a common framework that all source-dependent > tools could use. I see, so I guess the short answer is "there's just no easy way to do it for now". Perhaps I'll write a Perl script that will do it for me while waiting for a standardized solution. The issue of source/binary version mismatches shouldn't be a problem as long as the source I copy over is the same source I built from right? Or are you suggesting that sometimes the source is transformed during the build process before being compiled? > > > Second, I cannot create a windows build of GHC under cygwin. Looking at >> the Building Guide on the wiki suggests that this is indeed supported. >> > > Personally, I last built the head version > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.11.20090320 > > that way. The buildbots seem to succeed most of the time recently, > with some recent issues in stable: > > http://darcs.haskell.org/buildbot/ > > (whenever windows head/stable builds there, it is a good time to pull > patches;-) > > However, when I try to build it I get >> >> cabal-bin.exe: Cannot find the program 'ghc' at >> '/cygdrive/c/dev/haskell/ghc/ghc-6.10.1/bin/ghc' or on the path >> make[1]: *** [bootstrapping.conf] Error 1 >> make[1]: Leaving directory >> `/cygdrive/c/dev/haskell/ghc/ghc-6.10.1-src/libraries' >> make: *** [stage1] Error 2 >> >> There seems to be some unix/windows confusion here, because it's looking >> for >> an executable file named "ghc", when the actual executable name is >> "ghc.exe". >> > > Not just that. Cabal is also trying to find ghc via a cygwin path > (about which ghc-compiled binaries like Cabal don't know a thing). > > Are you sure you've configured for mingw? Otherwise the build > system will try to proceed in cygwin, as if for a unix platform. I'm pretty sure I'm NOT configured for MinGW when I was trying to build under Cygwin. I just assumed that the process would be completely independent of the mingw process. What do I need to do configure the cygwin environment for MinGW? > > > However, building under MSYS everything works perfectly. Is >> Cygwin just not supported, or do I need to change something here? I don't >> see any point in cluttering up my system with tons of extra software like >> MinGW, msys, etc if Cygwin works fine. >> > > Mingw provides the C compiler, msys or cygwin the build tools. > Even under cygwin, you still need to configure to use the mingw > C compiler and linker (not the cygwin versions of these). > > Simon Marlow has recently cleaned up the build instructions > http://hackage.haskell.org/trac/ghc/wiki/Building > > If there's still anything missing or ambiguous in there, please provide > details, questions, or improve the wiki pages. We all like those > instructions to be accurate, for the next time we start from scratch!-) Is there a way to download a windows binary distribution of GCC myself and have Cygwin use my version of GCC and Cygwin's version of all tools? It just seems a little superfluous to have two unix environments (Cygwin and mingw) and two separate copies of GCC installed (since I already use windows GCC for other reasons) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090329/2aef33c2/attachment.htm From colin at colina.demon.co.uk Mon Mar 30 03:03:47 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Mar 30 02:51:06 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <1238362226-sup-9717@existential.local> (Austin Seipp's message of "Sun\, 29 Mar 2009 16\:31\:11 -0500") References: <1238362226-sup-9717@existential.local> Message-ID: >>>>> "Austin" == Austin Seipp writes: Austin> Excerpts from Colin Paul Adams's message of Sun Mar 29 Austin> 09:29:43 -0500 2009: >> I was getting errors somewhere in haddock about some ambiguous >> function, so I did a darcs pull to see if that would pull in a >> fix for the problem (unfortunately I didn't make a note of the >> errors). >> >> But now the compile fails earlier with errors in >> deSugar/DsMeta.hs: >> >> deSugar/DsMeta.hs:471:48: Not in scope: type constructor or >> class `TH.InlineSpecQ' Austin> Sounds like it has to do with a template haskell update. >> From the root of the source tree, do: Austin> $ make distclean $ ./darcs-all pull -a Austin> $ ./configure ... $ make ... Austin> like usual. Thanks. That gets me bsak to the original problem, which is: [23 of 24] Compiling Haddock.Backends.Html ( src/Haddock/Backends/Html.hs, dist-install/build/haddock/haddock-tmp/Haddock/Backends/Html.o ) src/Haddock/Backends/Html.hs:1495:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 src/Haddock/Backends/Html.hs:1511:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 etc. -- Colin Adams Preston Lancashire From simonpj at microsoft.com Mon Mar 30 03:56:00 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Mar 30 03:45:14 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> The HEAD and several other packages travel together: if you update one you must update the others. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries In this case you need to update template-haskell. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Colin Paul Adams | Sent: 29 March 2009 15:30 | To: glasgow-haskell-users@haskell.org | Subject: Unable to compile ghc from darcs | | I was getting errors somewhere in haddock about some ambiguous | function, so I did a darcs pull to see if that would pull in a fix for | the problem (unfortunately I didn't make a note of the errors). | | But now the compile fails earlier with errors in deSugar/DsMeta.hs: | | deSugar/DsMeta.hs:471:48: | Not in scope: type constructor or class `TH.InlineSpecQ' | | deSugar/DsMeta.hs:504:16: | Not in scope: type constructor or class `TH.TyVarBndr' | | deSugar/DsMeta.hs:538:50: | Not in scope: type constructor or class `TH.TyVarBndr' | | deSugar/DsMeta.hs:640:29: | Not in scope: type constructor or class `TH.Kind' | | etc. | | Is the code in darcs supposed to be compilable normally? | | And what can I do about such situations? Just report them here? | -- | Colin Adams | Preston Lancashire | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From donnie at darthik.com Mon Mar 30 04:01:57 2009 From: donnie at darthik.com (Donnie Jones) Date: Mon Mar 30 03:49:14 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Hello Colin, In my working with GHC, I have found this page very helpful since it succinctly outlines the steps for Rebuilding GHC and ensuring you are up-to-date with everything GHC needs: http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding Best of luck! -- Donnie Jones On Mon, Mar 30, 2009 at 2:56 AM, Simon Peyton-Jones wrote: > The HEAD and several other packages travel together: if you update one you must update the others. > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries > > In this case you need to update template-haskell. > > Simon > > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- > | bounces@haskell.org] On Behalf Of Colin Paul Adams > | Sent: 29 March 2009 15:30 > | To: glasgow-haskell-users@haskell.org > | Subject: Unable to compile ghc from darcs > | > | I was getting errors somewhere in haddock about some ambiguous > | function, so I did a darcs pull to see if that would pull in a fix for > | the problem (unfortunately I didn't make a note of the errors). > | > | But now the compile fails earlier with errors in deSugar/DsMeta.hs: > | > | deSugar/DsMeta.hs:471:48: > | ? ? Not in scope: type constructor or class `TH.InlineSpecQ' > | > | deSugar/DsMeta.hs:504:16: > | ? ? Not in scope: type constructor or class `TH.TyVarBndr' > | > | deSugar/DsMeta.hs:538:50: > | ? ? Not in scope: type constructor or class `TH.TyVarBndr' > | > | deSugar/DsMeta.hs:640:29: > | ? ? Not in scope: type constructor or class `TH.Kind' > | > | etc. > | > | Is the code in darcs supposed to be compilable normally? > | > | And what can I do about such situations? Just report them here? > | -- > | Colin Adams > | Preston Lancashire > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From claus.reinke at talk21.com Mon Mar 30 04:29:24 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Mar 30 04:16:48 2009 Subject: Few problems with building GHC References: <478231340903291456q320f1256q2750ed4933a25d0f@mail.gmail.com> <478231340903291601k11519a28r494ec835bb924997@mail.gmail.com> Message-ID: <5210A3437B564283881D6871EA00C2FA@cr3lt> > I see, so I guess the short answer is "there's just no easy way to do it for > now". Perhaps I'll write a Perl script that will do it for me while waiting > for a standardized solution. The issue of source/binary version mismatches > shouldn't be a problem as long as the source I copy over is the same source > I built from right? Or are you suggesting that sometimes the source is > transformed during the build process before being compiled? It isn't just a matter of scripting (you could 'cabal unpack' all your installed packages somewhere), but of source code interpretation being partially package-based (eg, if you have two packages providing alternative implementations of the same modules, it is cabal's job to organize the hiding of one while building or using the other; if you just use ghc's import chasing over a list of import directories containing the sources of both packages, things are likely to fail). If you keep the sources around from the build, at least all the preprocessing and configuration will have been done and match the installed binaries. If you get something working (for which editor, btw?), you might want to add your experiences to one of those tickets, or the wiki. It isn't that this would be impossible, just not trivial, so we have to keep adding information on possible solutions/issues until a viable design for a standard solution emerges. >> Are you sure you've configured for mingw? Otherwise the build >> system will try to proceed in cygwin, as if for a unix platform. > > I'm pretty sure I'm NOT configured for MinGW when I was trying to build > under Cygwin. I just assumed that the process would be completely > independent of the mingw process. What do I need to do configure the cygwin > environment for MinGW? Not configure cygwin, but configure the ghc build (so that it will pick up mingw gcc/ld even while using cygwin sh/make/configure). See wiki:Building for details. >> However, building under MSYS everything works perfectly. Is >>> Cygwin just not supported, or do I need to change something here? I don't >>> see any point in cluttering up my system with tons of extra software like >>> MinGW, msys, etc if Cygwin works fine. >> >> Mingw provides the C compiler, msys or cygwin the build tools. >> Even under cygwin, you still need to configure to use the mingw >> C compiler and linker (not the cygwin versions of these). >> >> Simon Marlow has recently cleaned up the build instructions >> http://hackage.haskell.org/trac/ghc/wiki/Building >> >> If there's still anything missing or ambiguous in there, please provide >> details, questions, or improve the wiki pages. We all like those >> instructions to be accurate, for the next time we start from scratch!-) > > Is there a way to download a windows binary distribution of GCC myself and > have Cygwin use my version of GCC and Cygwin's version of all tools? It > just seems a little superfluous to have two unix environments (Cygwin and > mingw) and two separate copies of GCC installed (since I already use windows > GCC for other reasons) mingw is a windows binary distribution of gcc/ld/.. (which create windows-native executables) - you need this. msys and cygwin are unix-like environments (sh/make/configure/ ..) - you need exacty one of these. cygwin has its own versions of gcc/ld (which generate cygwin-dependent executables*) - you don't need these (not likely to work for ghc builds). Most of which I mentioned before, as does the wiki. Claus *cygwin's gcc/ld used to have a native mode, but the sources for that may not be in sync with the now separate mingw gcc/ld, may not do the same thing, and are not likely to work for ghc builds From colin at colina.demon.co.uk Mon Mar 30 07:23:46 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Mon Mar 30 07:11:09 2009 Subject: Unable to compile ghc from darcs In-Reply-To: (Donnie Jones's message of "Mon\, 30 Mar 2009 03\:01\:57 -0500") References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: >>>>> "Donnie" == Donnie Jones writes: Donnie> Hello Colin, In my working with GHC, I have found this Donnie> page very helpful since it succinctly outlines the steps Donnie> for Rebuilding GHC and ensuring you are up-to-date with Donnie> everything GHC needs: Donnie> http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding Thanks. I did this and it cured the TH problems, but I still have haddock problems: src/Haddock/Backends/Html.hs:1495:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 src/Haddock/Backends/Html.hs:1511:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 src/Haddock/Backends/Html.hs:1515:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 src/Haddock/Backends/Html.hs:1532:4: Ambiguous occurrence `maybeParen' It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 -- Colin Adams Preston Lancashire From ndmitchell at gmail.com Mon Mar 30 08:31:54 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 30 08:19:11 2009 Subject: copyFile and thread safety Message-ID: <404396ef0903300531h75e5d376y1538ebc321a98b8@mail.gmail.com> Hi, Using GHC 6.8.3, the copyFile routine isn't thread safe - it crashes when two threads try and open the same file. I think that improvements were made to avoid security race conditions in GHC 6.10.1 (or the base library associated with it), and as a nice side effect they seem to have fixed the copyFile issues. However, it would be nice if someone could assure me that the copyFile issues were real but are now fixed. Replicating them is hard, but they randomly occur during a 1-hour build on my laptop, but not my desktop. I also note that copyFile starts with the process id and increments looking for a free filename. While that's fantastic if you are avoiding races with other processes (as I think the improvements were intended to address), it's not so great for avoiding races within the same process when different threads attempt to copy lots of files at once. In doing this, I suspect I've suffered lots of retries in the temporary name creation algorithm - should I be concerned about the performance aspect of this? Would an atomicModifyIORef and global temp file counter be a good idea? For now, I've got no immediate problems as I simply shell out to "cp" to do the copying - but it would be nice if the Haskell worked too. Thanks Neil From choener at tbi.univie.ac.at Mon Mar 30 12:46:31 2009 From: choener at tbi.univie.ac.at (Christian Hoener zu Siederdissen) Date: Mon Mar 30 12:33:57 2009 Subject: Control.Parallel.Strategies.parMap CPU usage In-Reply-To: <49BA71F5.5020107@gmail.com> References: <49BA6BAE.8040407@tbi.univie.ac.at> <49BA71F5.5020107@gmail.com> Message-ID: <49D0F767.4040506@tbi.univie.ac.at> Hi, having tried the 6.10.2rc1 release candidate, I still find that "parMap rnf xs" on a list of thunks xs does not optimally use all available processors. With N the number of cores, I still see that each block of N thunks (say: x_1 and x_2) has to be calculated before (x3 and x4) will be started. Would there be hope that compiling the latest head instead of 2009/03/14 (rc1) gives better results? Note that each x_(k+1) is computationally more demanding than x_k. Gruss, Christian Simon Marlow wrote: > Christian Hoener zu Siederdissen wrote: > >> when using parMap (or parList and demanding) I see a curious pattern >> in CPU usage. >> Running "parMap rnf fib [1..100]" gives the following pattern of used >> CPUs: >> 4,3,2,1,4,3,2,1,... > > How did you find out which CPU is being used? > >> The fib function requires roughly two times the time if we go from >> fib(n) to fib(n+1), meaning that calculating the next element in the >> list always takes longer than the current. What I would like is a >> version of parMap that directly takes a free CPU and lets it calculate >> the next result, giving the usage pattern 4,4,4,4,... > > In GHC you don't have any control over which CPU is used to execute a > spark. We use dynamic load-balancing, which means the work distribution > is essentially random, and will change from run to run. > > If you want more explicit control over your work distribution, try using > GHC.Conc.forkOnIO. > > Also note that the implementation of much of this stuff is changing > rapidly, so you might want to try a recent snapshot. Take a look at our > paper, if you haven't already: > > http://www.haskell.org/~simonmar/papers/multicore-ghc.pdf > > Cheers, > Simon From dons at galois.com Mon Mar 30 13:01:01 2009 From: dons at galois.com (Don Stewart) Date: Mon Mar 30 12:49:20 2009 Subject: Control.Parallel.Strategies.parMap CPU usage In-Reply-To: <49D0F767.4040506@tbi.univie.ac.at> References: <49BA6BAE.8040407@tbi.univie.ac.at> <49BA71F5.5020107@gmail.com> <49D0F767.4040506@tbi.univie.ac.at> Message-ID: <20090330170101.GC3693@whirlpool.galois.com> choener: > Hi, > > having tried the 6.10.2rc1 release candidate, I still find that "parMap > rnf xs" on a list of thunks xs does not optimally use all available > processors. With N the number of cores, I still see that each block of N > thunks (say: x_1 and x_2) has to be calculated before (x3 and x4) will be > started. > > Would there be hope that compiling the latest head instead of 2009/03/14 (rc1) gives better results? > Yes, definitely. The HEAD implements all the `par` improvements described in the recent "multicore runtime" paper, as well as giving detailed runtime statistics on spark use. From choener at tbi.univie.ac.at Mon Mar 30 19:36:48 2009 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Mon Mar 30 19:19:13 2009 Subject: Control.Parallel.Strategies.parMap CPU usage In-Reply-To: <20090330170101.GC3693@whirlpool.galois.com> References: <49BA6BAE.8040407@tbi.univie.ac.at> <49BA71F5.5020107@gmail.com> <49D0F767.4040506@tbi.univie.ac.at> <20090330170101.GC3693@whirlpool.galois.com> Message-ID: <20090330233648.GA9409@workstation> Hi, thank you very much Simon & Don, for the answers. The latest head gives great results on parallel programs. All cores are now always at work as I hoped for. So, too, thanks to everybody involved in the multicore improvements -- they should come very handy. :-) Thanks again, Christian * Don Stewart [30.03.2009 19:02]: > choener: > > Hi, > > > > having tried the 6.10.2rc1 release candidate, I still find that "parMap > > rnf xs" on a list of thunks xs does not optimally use all available > > processors. With N the number of cores, I still see that each block of N > > thunks (say: x_1 and x_2) has to be calculated before (x3 and x4) will be > > started. > > > > Would there be hope that compiling the latest head instead of 2009/03/14 (rc1) gives better results? > > > > Yes, definitely. The HEAD implements all the `par` improvements > described in the recent "multicore runtime" paper, as well as giving > detailed runtime statistics on spark use. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090331/98716bcf/attachment-0001.bin From conal at conal.net Mon Mar 30 22:44:36 2009 From: conal at conal.net (Conal Elliott) Date: Mon Mar 30 22:31:51 2009 Subject: spurious "non-exhaustive" pattern warnings? Message-ID: -- Why do I get warnings about non-exhaustive pattern matches in the -- following code? Is the compiler just not clever enough to notice that -- the uncovered cases are all type-incorrect? (ghc 6.11.20090115) {-# LANGUAGE TypeFamilies, EmptyDataDecls, TypeOperators , GADTs, KindSignatures , FlexibleInstances, FlexibleContexts #-} {-# OPTIONS_GHC -Wall #-} import Control.Applicative (Applicative(..)) data Z data S n infixr 1 :< data Vec :: * -> * -> * where ZVec :: Vec Z a (:<) :: a -> Vec n a -> Vec (S n) a -- todo: infix op for SVec instance Functor (Vec n) where fmap _ ZVec = ZVec fmap f (a :< u) = f a :< fmap f u instance Applicative (Vec Z) where pure _ = ZVec ZVec <*> ZVec = ZVec -- Warning: Pattern match(es) are non-exhaustive -- In the definition of `<*>': -- Patterns not matched: -- (_ :< _) _ -- ZVec (_ :< _) instance Applicative (Vec n) => Applicative (Vec (S n)) where pure a = a :< pure a (f :< fs) <*> (x :< xs) = f x :< (fs <*> xs) -- Warning: Pattern match(es) are non-exhaustive -- In the definition of `<*>': -- Patterns not matched: -- ZVec _ -- (_ :< _) ZVec -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090330/fc1c9606/attachment.htm From simonpj at microsoft.com Tue Mar 31 03:12:07 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Mar 31 02:59:23 2009 Subject: spurious "non-exhaustive" pattern warnings? In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33507E1648A@EA-EXMSG-C334.europe.corp.microsoft.com> The overlap warning checker simply doesn't take account of GADTs. There's a long-standing project suggestion to fix this: http://hackage.haskell.org/trac/ghc/wiki/ProjectSuggestions Perhaps a good GSoc project. Simon From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 31 March 2009 03:45 To: glasgow-haskell-users@haskell.org Subject: spurious "non-exhaustive" pattern warnings? -- Why do I get warnings about non-exhaustive pattern matches in the -- following code? Is the compiler just not clever enough to notice that -- the uncovered cases are all type-incorrect? (ghc 6.11.20090115) {-# LANGUAGE TypeFamilies, EmptyDataDecls, TypeOperators , GADTs, KindSignatures , FlexibleInstances, FlexibleContexts #-} {-# OPTIONS_GHC -Wall #-} import Control.Applicative (Applicative(..)) data Z data S n infixr 1 :< data Vec :: * -> * -> * where ZVec :: Vec Z a (:<) :: a -> Vec n a -> Vec (S n) a -- todo: infix op for SVec instance Functor (Vec n) where fmap _ ZVec = ZVec fmap f (a :< u) = f a :< fmap f u instance Applicative (Vec Z) where pure _ = ZVec ZVec <*> ZVec = ZVec -- Warning: Pattern match(es) are non-exhaustive -- In the definition of `<*>': -- Patterns not matched: -- (_ :< _) _ -- ZVec (_ :< _) instance Applicative (Vec n) => Applicative (Vec (S n)) where pure a = a :< pure a (f :< fs) <*> (x :< xs) = f x :< (fs <*> xs) -- Warning: Pattern match(es) are non-exhaustive -- In the definition of `<*>': -- Patterns not matched: -- ZVec _ -- (_ :< _) ZVec -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090331/0eb975b1/attachment.htm From marlowsd at gmail.com Tue Mar 31 07:07:19 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 31 06:54:38 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <49D1F967.80503@gmail.com> Colin Paul Adams wrote: >>>>>> "Donnie" == Donnie Jones writes: > > Donnie> Hello Colin, In my working with GHC, I have found this > Donnie> page very helpful since it succinctly outlines the steps > Donnie> for Rebuilding GHC and ensuring you are up-to-date with > Donnie> everything GHC needs: > Donnie> http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding > > Thanks. > > I did this and it cured the TH problems, but I still have haddock > problems: > > src/Haddock/Backends/Html.hs:1495:4: > Ambiguous occurrence `maybeParen' > It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 > or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 > > src/Haddock/Backends/Html.hs:1511:4: > Ambiguous occurrence `maybeParen' > It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 > or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 > > src/Haddock/Backends/Html.hs:1515:4: > Ambiguous occurrence `maybeParen' > It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 > or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 > > src/Haddock/Backends/Html.hs:1532:4: > Ambiguous occurrence `maybeParen' > It could refer to either `Haddock.Backends.Html.maybeParen', defined at src/Haddock/Backends/Html.hs:1462:0 > or `GHC.maybeParen', imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 > Are you using a build tree made with lndir? If you, you probably want to link the _darcs directory from your source tree into your build tree. This will enable configure to generate a more accurate version number, which will probably fix the compile problem with Haddock. Cheers, Simon From colin at colina.demon.co.uk Tue Mar 31 07:15:36 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Mar 31 07:02:53 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <49D1F967.80503@gmail.com> (Simon Marlow's message of "Tue\, 31 Mar 2009 12\:07\:19 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: >> src/Haddock/Backends/Html.hs:1532:4: Ambiguous occurrence >> `maybeParen' It could refer to either >> `Haddock.Backends.Html.maybeParen', defined at >> src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', >> imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 >> Simon> Are you using a build tree made with lndir? If you, you probably want Simon> to link the _darcs directory from your source tree into Simon> your build tree. This will enable configure to generate a Simon> more accurate version number, which will probably fix the Simon> compile problem with Haddock. I don't think so. I am just typing ./configure and make within the source tree (the parent of the _darcs directory). Is this bad? -- Colin Adams Preston Lancashire From marlowsd at gmail.com Tue Mar 31 09:13:45 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 31 09:01:04 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> Message-ID: <49D21709.1000408@gmail.com> Colin Paul Adams wrote: >>>>>> "Simon" == Simon Marlow writes: > > >> src/Haddock/Backends/Html.hs:1532:4: Ambiguous occurrence > >> `maybeParen' It could refer to either > >> `Haddock.Backends.Html.maybeParen', defined at > >> src/Haddock/Backends/Html.hs:1462:0 or `GHC.maybeParen', > >> imported from GHC at src/Haddock/Backends/Html.hs:42:0-39 > >> > > Simon> Are you using a build tree made with lndir? If you, you probably want > Simon> to link the _darcs directory from your source tree into > Simon> your build tree. This will enable configure to generate a > Simon> more accurate version number, which will probably fix the > Simon> compile problem with Haddock. > > I don't think so. I am just typing ./configure and make within the > source tree (the parent of the _darcs directory). Is this bad? No, that should be fine. The Haddock build error indicates that either your Haddock sources are out of date with respect to your GHC sources, or Haddock thinks your GHC is a different version than it really is. What GHC are you using to bootstrap with, BTW? Cheers, Simon From colin at colina.demon.co.uk Tue Mar 31 09:20:06 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Mar 31 09:07:26 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <49D21709.1000408@gmail.com> (Simon Marlow's message of "Tue\, 31 Mar 2009 14\:13\:45 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> Are you using a build tree made with lndir? If you, you Simon> probably want to link the _darcs directory from your source Simon> tree into your build tree. This will enable configure to Simon> generate a more accurate version number, which will Simon> probably fix the compile problem with Haddock. >> >> I don't think so. I am just typing ./configure and make within >> the source tree (the parent of the _darcs directory). Is this >> bad? Simon> No, that should be fine. The Haddock build error indicates Simon> that either your Haddock sources are out of date with Simon> respect to your GHC sources, or Haddock thinks your GHC is Simon> a different version than it really is. Simon> What GHC are you using to bootstrap with, BTW? 6.11.20090319 (formerly bootstrapped from 6.10.1). So it used to work. haddock --version says 2.4.2 -- Colin Adams Preston Lancashire From marlowsd at gmail.com Tue Mar 31 09:33:14 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 31 09:20:35 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> Message-ID: <49D21B9A.40705@gmail.com> Colin Paul Adams wrote: >>>>>> "Simon" == Simon Marlow writes: > > Simon> Are you using a build tree made with lndir? If you, you > Simon> probably want to link the _darcs directory from your source > Simon> tree into your build tree. This will enable configure to > Simon> generate a more accurate version number, which will > Simon> probably fix the compile problem with Haddock. > >> > >> I don't think so. I am just typing ./configure and make within > >> the source tree (the parent of the _darcs directory). Is this > >> bad? > > Simon> No, that should be fine. The Haddock build error indicates > Simon> that either your Haddock sources are out of date with > Simon> respect to your GHC sources, or Haddock thinks your GHC is > Simon> a different version than it really is. > > Simon> What GHC are you using to bootstrap with, BTW? > > 6.11.20090319 (formerly bootstrapped from 6.10.1). Ah, there's your problem. In general you can't bootstrap GHC using a development snapshot, we only support building using fixed released versions. Cheers, Simon From donnie at darthik.com Tue Mar 31 10:27:54 2009 From: donnie at darthik.com (Donnie Jones) Date: Tue Mar 31 10:15:07 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <49D21B9A.40705@gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> Message-ID: Hello Simon and Colin, This information is available on the Prequisites page of the GHC wiki; however, it's buried at the bottom of the page. I have updated the page to mention that a stable release version of GHC is needed when setting up for Linux and Windows, and I have changed the "Other" section to be called "Details" since this section describes in detail the software necessary for building GHC. http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites Hope this helps other users in the future. -- Donnie Jones On Tue, Mar 31, 2009 at 8:33 AM, Simon Marlow wrote: > Colin Paul Adams wrote: >>>>>>> >>>>>>> "Simon" == Simon Marlow writes: >> >> ? ?Simon> Are you using a build tree made with lndir? ?If you, you >> ? ?Simon> probably want to link the _darcs directory from your source >> ? ?Simon> tree into your build tree. ?This will enable configure to >> ? ?Simon> generate a more accurate version number, which will >> ? ?Simon> probably fix the compile problem with Haddock. >> ? ?>> ? ?>> I don't think so. I am just typing ./configure and make within >> ? ?>> the source tree (the parent of the _darcs directory). Is this >> ? ?>> bad? >> >> ? ?Simon> No, that should be fine. ?The Haddock build error indicates >> ? ?Simon> that either your Haddock sources are out of date with >> ? ?Simon> respect to your GHC sources, or Haddock thinks your GHC is >> ? ?Simon> a different version than it really is. >> >> ? ?Simon> What GHC are you using to bootstrap with, BTW? >> >> 6.11.20090319 (formerly bootstrapped from 6.10.1). > > Ah, there's your problem. ?In general you can't bootstrap GHC using a > development snapshot, we only support building using fixed released > versions. > > Cheers, > ? ? ? ?Simon > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From colin at colina.demon.co.uk Tue Mar 31 10:49:19 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Mar 31 10:36:36 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <49D21B9A.40705@gmail.com> (Simon Marlow's message of "Tue\, 31 Mar 2009 14\:33\:14 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: >> 6.11.20090319 (formerly bootstrapped from 6.10.1). Simon> Ah, there's your problem. In general you can't bootstrap Simon> GHC using a development snapshot, we only support building Simon> using fixed released versions. So I re-installed ghc 6.10.1. Same problem. N.B. haddock --version now reports 2.3.0 -- Colin Adams Preston Lancashire From marlowsd at gmail.com Tue Mar 31 10:56:52 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 31 10:44:11 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> Message-ID: <49D22F34.60907@gmail.com> Donnie Jones wrote: > Hello Simon and Colin, > > This information is available on the Prequisites page of the GHC wiki; > however, it's buried at the bottom of the page. I have updated the > page to mention that a stable release version of GHC is needed when > setting up for Linux and Windows, and I have changed the "Other" > section to be called "Details" since this section describes in detail > the software necessary for building GHC. > > http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites Thanks Donnie. I've also just modified the configure script so it issues the following helpful message: configure: error: /home/simonmar/builds/testing/ghc/stage2-inplace/ghc is a development snapshot of GHC, version 6.11 Bootstrapping using this version of GHC is not supported, and may not work. Use --enable-bootstrap-with-devel-snapshot to try it anyway, or --with-ghc to specify a different GHC to use. Cheers, Simon From marlowsd at gmail.com Tue Mar 31 11:34:34 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Mar 31 11:21:56 2009 Subject: Unable to compile ghc from darcs In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> Message-ID: <49D2380A.4000006@gmail.com> Colin Paul Adams wrote: >>>>>> "Simon" == Simon Marlow writes: > > >> 6.11.20090319 (formerly bootstrapped from 6.10.1). > > Simon> Ah, there's your problem. In general you can't bootstrap > Simon> GHC using a development snapshot, we only support building > Simon> using fixed released versions. > > So I re-installed ghc 6.10.1. > > Same problem. > > N.B. haddock --version now reports 2.3.0 I have to ask - you did do a complete 'make distclean' etc. before rebuilding? If so, could you send me a complete log of the build. Cheers, Simon From colin at colina.demon.co.uk Tue Mar 31 11:38:35 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Mar 31 11:25:49 2009 Subject: Unable to compile ghc from darcs In-Reply-To: <49D2380A.4000006@gmail.com> (Simon Marlow's message of "Tue\, 31 Mar 2009 16\:34\:34 +0100") References: <638ABD0A29C8884A91BC5FB5C349B1C33507E15BCB@EA-EXMSG-C334.europe.corp.microsoft.com> <49D1F967.80503@gmail.com> <49D21709.1000408@gmail.com> <49D21B9A.40705@gmail.com> <49D2380A.4000006@gmail.com> Message-ID: >>>>> "Simon" == Simon Marlow writes: Simon> Colin Paul Adams wrote: >>>>>>> "Simon" == Simon Marlow writes: >> >> >> 6.11.20090319 (formerly bootstrapped from 6.10.1). >> Simon> Ah, there's your problem. In general you can't bootstrap Simon> GHC using a development snapshot, we only support building Simon> using fixed released versions. >> >> So I re-installed ghc 6.10.1. >> >> Same problem. >> >> N.B. haddock --version now reports 2.3.0 Simon> I have to ask - you did do a complete 'make distclean' Simon> etc. before rebuilding? I did. Simon> If so, could you send me a complete log of the build. My xterm window doesn't have a big enough buffer. Should I run the complete procedure (starting with make distclean) all over again, diverting output and error to a file? -- Colin Adams Preston Lancashire From conal at conal.net Tue Mar 31 19:18:03 2009 From: conal at conal.net (Conal Elliott) Date: Tue Mar 31 19:05:15 2009 Subject: GADTs with strict fields? Message-ID: Do strict fields work with GADTs? If so, what's the syntax for the strictness annotations? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090331/a2fb9db0/attachment.htm From conal at conal.net Tue Mar 31 19:54:17 2009 From: conal at conal.net (Conal Elliott) Date: Tue Mar 31 19:41:29 2009 Subject: GADTs with strict fields? In-Reply-To: References: Message-ID: I got an answer: precede the argument types by a "!". I didn't realize that type applications then have to be parenthesized. On Tue, Mar 31, 2009 at 4:18 PM, Conal Elliott wrote: > Do strict fields work with GADTs? If so, what's the syntax for the > strictness annotations? - Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090331/4c7a1083/attachment.htm From mad.one at gmail.com Wed Mar 18 17:13:06 2009 From: mad.one at gmail.com (Austin Seipp) Date: Sat May 9 10:16:47 2009 Subject: A patch to fix getNumberOfProcessors() on OS X Message-ID: <1237411434-sup-707@existential.local> (Tried sending to cvs-ghc, said it was blocked for moderation because it matched a certain pattern...) Hello, I have a patch to fix the runtime system's getNumberOfProcessors() function to work properly on OS X and detect the number of CPUs. However, when I run validate, these are the final results: OVERALL SUMMARY for test run started at Tue Mar 17 21:34:36 CDT 2009 2318 total tests, which gave rise to 8661 test cases, of which 0 caused framework failures 6662 were skipped 1923 expected passes 74 expected failures 1 unexpected passes 1 unexpected failures Unexpected passes: hpc_ghc_ghci(normal) Unexpected failures: break017(ghci) Are these to be expected on OS X, or did my patch really break something? Patch is attached. Austin -------------- next part -------------- A non-text attachment was scrubbed... Name: osx_nproc.dpatch Type: application/octet-stream Size: 193337 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20090318/650b8bac/osx_nproc-0001.obj