Re: getMBlocks
Rich Fought wrote: I'm still chasing down a memory leak in my server application written in Haskell using GHC 6.4.x under MinGW/MSYS. In the scenario described below, I am repeating the same server request once per second continuously. After utilizing some memory monitoring tools I've discovered that memory usage fluctuates within in a range of approximately 850 KB (I assume as garbage is collected), What tool(s) did you use to obtain this figure? but at regular intervals the range gets bumped up by ~ 1 MB. So in effect I get a stair-stepping of memory usage that keeps repeating until memory runs out. WinDbg has revealed that this stepping coincides with the GHC runtime function getMBlocks(). My question is: what conditions affect when the runtime determines that it needs more memory? Is it a pure no more room trigger or is there some sort of algorithm behind it? The block allocation layer grabs another Mb whenever it runs out, that's all. The vast majority of the blocks in use by the storage manager will be either free or assigned to the heap, so the most likely possibility is that you do have a space leak (although that disagrees with the 850Kb figure you gave above). I assume that this behavior means I still have a space leak somewhere in my Haskell code, though none of leak check tools I utilize indicate such. Did you try GHC's heap profiler? Or simply running your program with +RTS -Sstderr will give you a clue about the shape of the heap usage - each line is a single GC, and it includes the amount of live data at that point. If your program has a flat heap profile and yet is still grabbing more memory, then something else is going on. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Graphics library very slow
Simon Peyton-Jones wrote: By this code is currently broken, I'm sure you are right, but which code you mean exactly? The Win32 binding for GHC? Or the Hugs Graphics Library (HGL) implementation for GHC? It'd be good to have a Trac bug report, specifying as precisely as possible what is broken. There is already a ticket open for this: http://hackage.haskell.org/trac/ghc/ticket/742 Graphics.SOE runs very slowly under win32. I propose that we do not ship the current HGL in 6.6. Any objections? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Evaluating expressions in Visual Haskell
Vyacheslav Akhmechet wrote: I apologize if this question has been asked before, but I couldn't find an FAQ or the answer online. Does Visual Haskell have support for evaluating expressions? I tried a few things (like highlighting an expression, rightclicking, and looking for evaluate option) but couldn't find anything. No, that feature isn't implemented. It is something we'd like to do, though. If this feature is missing, is it planned? Also, what is a good way to do this together with Visual Haskell? I could, of course, open an interpreter in a command window, load appropriate modules, and evaluate expressions from there but is there a more integrated way? That's the only way right now, I'm afraid. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.6 plans and status
Simon Marlow wrote: Chris Kuklewicz wrote: Would a new and expanded Regex package (Test.Regex.Lazy) be something that could be included in the 6.6.0 libraries? What is the best practice for getting it included? Since we're aiming to include fewer libraries under the GHC umbrella, not more, this wouldn't be the right approach. Also, I'm sure you want the ability to release Text.Regex.Lazy independently of GHC, so tying it to the GHC release cycle would be unduly restrictive. Possibly true. I do want to extract the existing Text.Regex(.Posix) from the base package. base seems the wrong place. So we should think about what structure we want for regex packages. Here's one possible plan: regex-baseshared regex code regex-posixthe POSIX backend regex-pcrethe PCRE backend ... That could work well. It would not involved too much pulling apart. Once small quirk is there is the old Text.Regex API and a new JRegex-style API. We should have one default implementation that provides regexes over Strings and ByteStrings. I don't really mind which backend that is, as long as it is fast and BSD-licensed. A default backend has to be dependably present. That means either keeping the current Posix backend, adding a dependency on PCRE, or using the Haskell/Parsec backend. The problem is that String is very inefficient with Posix or PCRE and ByteString is slightly inefficient with Haskell/Parsec. We could then include a subset of these packages (optionally) in GHC binary distributions, so that users would have access to basic regex functionality out of the box. How does that sound? That seems like the best plan. Ah, I just realised that GHC itself uses regexes in a couple of places, so I do need to include basic (String) regex functionality in the libraries. I assume that is the Posix Text.Regex syntax. So you need support for this syntax in GHC. So we could either: - work on regex-base/regex-posix for inclusion in GHC, or I could prepare this for you. - I could just extract Text.Regex(.Posix) from the base package into a separate package. obviously the first option is better, but time is short. Let me know what you think. Cheers, Simon I'll assemble a version organized like that this week. Important question: Should I be planning to install alongside the current Text.Regex(.Posix) or planning on replacing them? (With an identical API)? -- Chris ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.6 plans and status
Chris Kuklewicz wrote: That could work well. It would not involved too much pulling apart. Once small quirk is there is the old Text.Regex API and a new JRegex-style API. Is it possible to provide both? Perhaps deprecating the current API? A default backend has to be dependably present. That means either keeping the current Posix backend, adding a dependency on PCRE, or using the Haskell/Parsec backend. I'm not keen on adding a PCRE dependency. We already include an implementation of POSIX regexes in GHC itself (libraries/base/cbits/regex) which tends to get used on Windows where there isn't an implementation of POSIX regexes The problem is that String is very inefficient with Posix or PCRE and ByteString is slightly inefficient with Haskell/Parsec. Do you have any measurements (rough measurements would be fine)? When you say very inefficient, by what factor is the Parsec implementation faster than using the Posix one for Strings? If we were to use the Parsec implementation, that pulls in another dependency. Not out of the question, but to be avoided if possible. So we could either: - work on regex-base/regex-posix for inclusion in GHC, or I could prepare this for you. Great, thanks! I'll assemble a version organized like that this week. Important question: Should I be planning to install alongside the current Text.Regex(.Posix) or planning on replacing them? (With an identical API)? We want to replace Text.Regex. So ideally you want to do this in a GHC tree, so you can remove the old Text.Regex and replace with yours. If this is too difficult, then you could develop it separately (as Text.Regex.New, or something), and I'll make the relevant changes when I import it. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.6 plans and status
Simon Marlow wrote: Chris Kuklewicz wrote: That could work well. It would not involved too much pulling apart. Once small quirk is there is the old Text.Regex API and a new JRegex-style API. Is it possible to provide both? Perhaps deprecating the current API? It is possible to provide the old and new. The old was only defined for the String type and this probably will not be changed (at least at first). A default backend has to be dependably present. That means either keeping the current Posix backend, adding a dependency on PCRE, or using the Haskell/Parsec backend. I'm not keen on adding a PCRE dependency. We already include an implementation of POSIX regexes in GHC itself (libraries/base/cbits/regex) which tends to get used on Windows where there isn't an implementation of POSIX regexes Ah. That is how you are doing it. The problem is that String is very inefficient with Posix or PCRE and ByteString is slightly inefficient with Haskell/Parsec. Do you have any measurements (rough measurements would be fine)? When you say very inefficient, by what factor is the Parsec implementation faster than using the Posix one for Strings? This whole Text.Regex.Lazy project was born from the computer language shootout. , http://haskell.org/hawiki/RegexDna . The Text.Regex(.Posix) that came with GHC timed out (hours!). The pure haskell/parsec version took about 2 minutes. That is the meaning very inefficient for repeated use of Text.Regex(.Posix) on String: more than two orders of magnitude, since it is not caching the CString that it marshals. If we were to use the Parsec implementation, that pulls in another dependency. Not out of the question, but to be avoided if possible. The only nonparsec/nonlibrary version is a simple DFA which is too simple for many uses. To get what people expect from regular expressions you need posix library, pcre library, my parsec parser, or find someone else's regex implementation in haskell. Or the parsec version could eventually be rewritten to not depend on parsec by implementing its own parser monad. To keep a Posix default backend the libraries/base/cbits/regex may need to become part of regex-posix. That would be a learning curve for me as I have no ghc on windows experience, though I have a computer for it next to me. So I might need help later for that. So we could either: - work on regex-base/regex-posix for inclusion in GHC, or I could prepare this for you. Great, thanks! The re-organization is in progress (hooray for darcs mv). After re-organization will come the doc/Haddock clean up to match. After that comes the unit testing clean up (I have some HUnit and QuickCheck now). Then, time permitting, benchmarks. I'll assemble a version organized like that this week. Important question: Should I be planning to install alongside the current Text.Regex(.Posix) or planning on replacing them? (With an identical API)? We want to replace Text.Regex. So ideally you want to do this in a GHC tree, so you can remove the old Text.Regex and replace with yours. If this is too difficult, then you could develop it separately (as Text.Regex.New, or something), and I'll make the relevant changes when I import it. I will make such a Text.Regex.New that fakes the old API. I'll make it use the posix backend, but that can be changed via an import statement. I suggest removing the old Text.Regex.Posix module. People will be able to make better use of the new API for doing this. -- Chris ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
wislist item: more control over branch prediction
So now that GHC is so good at producing really fast low level code (see
ByteString benchmarks) we start to encounter low level gubbins where to
get the fastest possible code we need slightly more influence over
branch prediction.
In the code for ByteString's 'writeStrUp/Dn' functions we're doing a
tight loop writing bytes to memory.
The first version looks much like this:
loop fp n off s = case next s of
Done - return $! PS fp 0 off
Skips' - loop fp n off s'
Yield x s' - do
withForeignPtr fp $ \p - pokeByteOff p off x
loop fp n (off+1) s'
When we get to the end of a memory block we need to double the size of
the memory block and carry on. So this adds an additional conditional
test into this loop.
loop fp n off s = case next s of
Done - trimUp fp n off
Skips' - loop fp n off s'
Yield x s'
| n == off - realloc fp n off s' x
| otherwise - do
withForeignPtr fp $ \p - pokeByteOff p off x
loop fp n (off+1) s'
There are dramatic differences between equivalent forms of code. Just by
reversing the order of the (n==off) test one form I can process 50Mb of
data in 0.20 seconds and in the other it takes 0.34 seconds.
That is:
| n == off - realloc fp n off s' x
| otherwise - do ...
vs
| n /= off - do ...
| otherwise - realloc fp n off s' x
I think that this is all down to branch prediction and the arrangement
of basic blocks. On a modern CPU correctly predicted branches are nearly
free while mis-predicted branches are very costly due to stalled
pipelines etc.
In gcc they have a branch prediction framework. It annotates
conditionals with prediction information. It then uses that during code
generation to do things like arranging basic blocks so that unlikely
blocks are moved out of line. It gets the prediction information from a
few sources. One is a simple static branch predictor, for example
branches back to to the beginning of a loop are likely to be taken and
branches to error functions are not. gcc even has a profile feedback
system to find the real probabilities of branches from a sample run of
the program. It also has a user annotation __builtin_expect() which many
C projects use in the form of a macro:
if (unlikely(x==0)) { ...
The Linux kernel uses this fairly heavily to move error handling code
out of the main 'fast path' code.
Anyway, so what I wish is that I could write something like:
loop fp n off s = case next s of
Done - {-# UNLIKELY #-}
trimUp fp n off
Skips' - loop fp n off s'
Yield x s'
| n == off - {-# UNLIKELY #-}
realloc fp n off s' x
| otherwise - do
withForeignPtr fp $ \p - pokeByteOff p off x
loop fp n (off+1) s'
The best approximating effect that I can use at the moment is to make
the unlikely realloc branch a local function in a where clause but mark
it with {-# NOINLINE #-} so that the code for the realloc case doesn't
pollute the tight loop for the normal fast case. Then the other
approximation is fiddling with the logic of the binary test and looking
at the benchmarks. The combination of these two techniques makes a
dramatic difference to the speed.
However I do need more control to do it reliably, while I was able to
make it work for writeStrUp, I could not find a combination to work for
writeStrDn - we loose about 50% performance when we add the realloc
branch. So a slightly more reliable method to hint at the likelihood of
conditionals would make this kind of low level code faster and easier to
write.
Some time ago as a quick hack I did add a branch prediction annotation
to the CMM conditional constructor. I only used it in the C backend to
turn it into uses of gcc's __builtin_expect(). I also didn't connect it
to the front end so I didn't have any high level static branch
prediction (which could be done by looking for branches with recursive
calls or calls to error etc). The only place I did actually use it was
in the heap check and stack check. I assumed that it would be
advantageous to predict heap and stack overflow branches as not taken.
It was only a quick hack - I didn't do any benchmarks to see if it had
any effect.
Anyway, just a thought, and of course not something we should be
thinking about 'til post 6.6.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Lookup module and package defining x?
$ghc-pkg --where-from ParseError
package parsec: defining modules: Text.ParserCombinators.Parsec.Error,
Text.ParserCombinators.Parsec
?
This is what I've done by now... It took me some days to notice that the
./ghc-pkg symlinks to ghc-pkg-6.5 which calls the ghc-pkg from /usr/lib/...
but not my modified version ;) ./ghc-pkg.bin was what I was looking for..
By now you can only search for modules...
I want to add support for functions..
I could use ghc -show-iface.. Problem: ghc takes about 0.2 s to launch on my
system. Dumping all installed ifaces (ghc -show-iface list of all hi files)
doesn't take much additional time..
That's why I want to include the MkIface module from ghc.. (beeing in another
directory)
I'm not sure where to add the -i option in the makefile so that ghc can find
the module..
One way would be adding the option to EXTRA_SRCS but I hope there is a better
possibility
Marc
{-# OPTIONS -fglasgow-exts #-}
---
whereFrom OPTIONS -fglasgow-exts #-}
18,20d17
#ifdef WHERE_FROM
import MkIface
#endif
185,189d181
#ifdef WHERE_FROM
$p where-from {id}\n ++
Which package/module contains this module/ declaration?\n ++
\n ++
#endif
237,240d228
#ifdef WHERE_FROM
[where-from, id] - do
whereFrom cli id
#endif
469,500d456
#ifdef WHERE_FROM
--
-
-- Where from find the modul or package containing the id
whereFrom :: [Flag] - String - IO ()
whereFrom flags id =
let simple_output = FlagSimpleOutput `elem` flags
in do db_stack - getPkgDatabases False flags
let all_pkgs = concat (map snd db_stack) :: [InstalledPackageInfo]
-- looking for modules with name id
let exposedModulesMatches = (exposed matching modules,
concatMap (getPkgNameAndModule exposedModules) all_pkgs ) ::
(String, [String])
let hiddenModulesMatches = (hidden matching modules,
concatMap (getPkgNameAndModule hiddenModules) all_pkgs )
-- looking for data
-- looking for type
-- looking for newtype
-- looking for functions
let matchingResult = filter ((/= []).snd) [exposedModulesMatches,
hiddenModulesMatches]
case matchingResult of
[] - putStrLn no matches found
results - do putStrLn maches :
mapM_ (\(category, matches) - putStrLn (category ++
:) mapM_ putStrLn matches) results
where getPkgNameAndModule modules pkginfo = [ formatFoundModule
((showPackageId.package) pkginfo) m | m - modules pkginfo, (m == id) ]
formatFoundModule pkg module_ = pkg ++ : ++ module_
scanPackage pkg scanModule = lifM2 (++) (concatMap (scanModule )
(exposedModules pkg))
(concatMap (scanModule
hidden) (hiddenModules pkg))
where scanModule hidden_text module_ =
#endif
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getMBlocks
Simon Marlow wrote: What tool(s) did you use to obtain this figure? This particular figure was gathered using perfmon logs collecting once per second from my application, while running in WinDbg to break on getMBlocks(). The particular memory variables tracked are Private Bytes and Working Set. Did you try GHC's heap profiler? Or simply running your program with +RTS -Sstderr will give you a clue about the shape of the heap usage - each line is a single GC, and it includes the amount of live data at that point. If your program has a flat heap profile and yet is still grabbing more memory, then something else is going on. Yes I did try the profiler, but I couldn't really garner any useful information from it. Most likely because I don't understand how to use it correctly. :) I should revisit this however, as I have since discovered and fixed some leaks. It should at least look different. Thanks, Rich ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.3 on FreeBSD
Simon Marlow wrote: An update on the GHC/FreeBSD front: I didn't manage to reproduce the reported threading bugs on a UP, will be trying on a MP shortly. Using -lthr instead of -pthread, I completed a test run on the dual proc box: OVERALL SUMMARY for test run started at Tue Aug 8 09:21:49 EDT 2006 1365 total tests, which gave rise to 6055 test cases, of which 0 caused framework failures 1034 were skipped 4944 expected passes 61 expected failures 4 unexpected passes 12 unexpected failures Unexpected passes: cholewo-eval(optasm,profasm) ffi009(optasm,profasm) Unexpected failures: barton-mangler-bug(normal,opt,prof,ghci,threaded) queryfdoption01(normal,opt,optasm,prof,profasm,threaded) rn.prog006(normal) Nothing to worry about here. I also discovered that we already have a fix in the HEAD's version of timeout that makes it work on FreeBSD (d'oh). The problem is that our timeout program forks and then calls system(), which forks again, and this is allegedly not allowed. I've merged that fix into STABLE now. I'm running the testsuite again with everything linked with -pthread and using the fixed timeout program. So far I haven't seen the other reported symptom, namely that the stage2 compiler sometimes hangs. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANN: TextRegexLazy-0.66 devel release
(when (compilesOk) (announce newVersion)) This is a development release announcement of TextRegexLazy The TextRegexLazy package is dead. Long Live [regex-base -- interfaces ,regex-compat -- replace Text.Regex ,regex-posix-- PosixRE backend ,regex-pcre -- PCRE backend ,regex-parsec -- My lazy Haskell backend ,regex-dfa -- DFA based on modified CTKLight (LGPL) ] Note: Everything is BSD licensed except the regex-dfa engine which is LGPL. The darcs repository at http://evenmere.org/~chrisk/trl/head/ has the new version. The regex-compat package is a single Text.Regex.New module that uses regex-posix to replace Text.Regex (I cut and pasted from the Text.Regex module and re-implemented some of the functions). The old Text.Regex.Posix module is bypassed (so it could be removed in the future). Changing the dependency to a different backend is as simply as changing the import statement. Changing from String to ByteString would be a simple search-and-replace (and import Data.ByteString). The regex-posix package does not have a personal copy of the posix regex library like the copy GHC brings to Windows: http://darcs.haskell.org/packages/base/cbits/regex/ If someone can get regex-posix working on Windows, then [regex-base,regex-posix,regex-compat] will be functionally ready to be included along with GHC. TODO: * Much Haddock fixing for the new module hierarchy * Point the test cases at the new packages * Benchmark -- Chris Kuklewicz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
fork and ghc
I want to modify jhc to take advantage of mutiple CPUs to help mitigate its prodigious computational requirements and was curious how well ghc compiled programs deal with forking? my initial plan is that once jhc determines which modules need to be recompiled, it will fork(2) off processes down each pass that can be done in parallel. however, I have no idea what the effect of just calling fork on the ghc runtime will be. both parent and child will continue on compiling code, so it won't be immediatly followed by an exec. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
dependingOn in 6.6
I was wondering if we could be sure to get dependingOn :: a - b - a dependingOn = in ghc 6.6? this has been discussed before, it is implemented in jhc and I have found all sorts of use for it as it can be used to control let floating and inlining in a nice general way and is trivial to implement. (one for ghc was posted before based on primitives it already implements) we just need to decide on a module to export it. the meaning is that x = ... `dependingOn` y returns x with an artificial dependency on y. so things using x cannot be floated out above where y is defined. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Building GHC on OS X
Hi, I've been using ghc on Mac OS X for a while now, so when I noticed Simon Marlow's call (made last month, but I just noticed it) for people to help with OS X, I thought, why not? Well, it turns out that I can't even build ghc, so I'm not likely to end up being much help. But it would be nice to at least be able to build the thing, so if anybody can help me... I'm trying to build GHC (6.5.?? ... version from darcs.haskell.org as of yesterday) on Mac OS X (10.4.7 ppc) bootstrapping from ghc 6.4.2 and gcc 4.0.1. ./configure; make does not work. On my initial try, I ran into the UNDO_DELETE, etc problems associated with Darwin's partial readline support described in ticket #766. The fix suggested in that ticket seems to work fine, but not until I installed the GNU readline library. (If the change to detect the broken Darwin readline is in the repository, it did not work for me). After fixing the readline problem, it looks like I can build at least part of the stage1 compiler -- but the build fails just after starting to build stage2. The final error is: ../compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches - fwarn-unused-imports -istage2/utils -istage2/basicTypes -istage2/ types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/ typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise - istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/ simplStg -istage2/codeGen -istage2/main -istage2/profiling - istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/ iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 - DGHCI -DBREAKPOINT -package template-haskell -threaded -cpp -fglasgow- exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser - package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -DDEBUG -H16M '-#include hschooks.h' -package-name ghc-6.5 - fgenerics -O -c utils/FastString.lhs -o stage2/utils/FastString.o - ohi stage2/utils/FastString.hi utils/FastString.lhs:73:0: Failed to load interface for `GHC.Exts': Could not find module `GHC.Exts': use -v to see a list of the files searched for ghc: 52487092 bytes, 5 GCs, 19236/19236 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.29 MUT (0.38 elapsed), 0.03 GC (0.04 elapsed) :ghc make[2]: *** [stage2/utils/FastString.o] Error 1 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 The first error that I can find comes when building ghc/libraries/ base (in stage1) ../../compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches - fwarn-unused-imports -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -package-name base-1.0 -O -dcore-lint -W -fno-warn-unused-matches -fwarn-unused-imports -keep-hc-files - fgenerics-c Data/Generics/Schemes.hs -o Data/Generics/Schemes.o - ohi Data/Generics/Schemes.hi Data/Generics/Schemes.hs:108:15: Couldn't match expected type `r' (a rigid variable) against inferred type `[a]' `r' is bound by the type signature for `listify' at Data/Generics/Schemes.hs:106:20 Expected type: r - r - r Inferred type: [a] - [a] - [a] In the first argument of `everything', namely `(++)' In the call (everything (++) ([] `mkQ` (\ x - if p x then [x] else []))) make[2]: *** [Data/Generics/Schemes.o] Error 1 After that, there are a handful of errors complaining about things that can't be found (e.g.) CPUTime.hs:5:0: Failed to load interface for `System.CPUTime': Could not find module `System.CPUTime': use -v to see a list of the files searched for make[2]: *** [CPUTime.o] Error 1 and Language/Haskell/TH/Syntax.hs:46:0: Failed to load interface for `Data.PackedString': Could not find module `Data.PackedString': use -v to see a list of the files searched for make[2]: *** [Language/Haskell/TH/Syntax.o] Error 1 There are six or seven more messages like those, but nothing severe enough to stop make until the problem where it can not find 'GHC.Exts'. I tried to brute force it with 'make -k', which went a lot further, but in the end build nothing useful. Anybody have any ideas? Or build instructions for OS X? Thanks, -david k. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
