leaky 0.3.0.3 → 0.4.0.0
raw patch · 11 files changed
+86/−149 lines, 11 filesdep ~deepseq-boundeddep ~seqaid
Dependency ranges changed: deepseq-bounded, seqaid
Files
- HTML/leaky.html +24/−26
- HTML/output.html +4/−4
- changelog.txt +5/−0
- cpphs.sh +2/−1
- deepseq-bounded-seqaid-leaky.html +1/−1
- leaky-full-incl-types.hs +3/−3
- leaky-full.hs +3/−3
- leaky-min.hs +1/−1
- leaky.cabal +38/−106
- leaky.hs +3/−3
- seqaidpp.sh +2/−1
HTML/leaky.html view
@@ -22,7 +22,7 @@ <p> <!-- http://neilmitchell.blogspot.ca/2013/11/acm-article-leaking-space.html -->-Quoting from Neil Mitchell's 2013 <a href="http://queue.acm.org/detail.cfm?id=2538488">article</a> in <em>ACM Queue</em>:+Quoting from Neil Mitchell’s 2013 <a href="http://queue.acm.org/detail.cfm?id=2538488">article</a> in <em>ACM Queue</em>: <p> <em style="display: block; margin-left: 15px; margin-right: 100px;">@@ -42,19 +42,19 @@ Such dire leaks can arise several times per week. <p>-<a id="r4"></a>-The problem stems from the lazy evaluation model of <span>Haskell <a href="#4">[4]</a></span>+<a id="r3"></a>+The problem stems from the lazy evaluation model of <span>Haskell <a href="#3">[3]</a></span> which has been discussed at length elsewhere (see <a href="#Related">Related</a>). <p> <a id="dig01s" class="dig-toggle-show" href='javascript:toggle("dig01");'>Show</a> <div id="dig01" class="digression"> <a id="dig01h" class="dig-toggle-hide" href='javascript:toggle("dig01");'>Hide</a><p style="margin-bottom: 0px;">-<a id="r3"></a>-All space leak degrades performance, and production-quality programs should eradicate as much leak behaviour as <span>possible. <a href="#3">[3]</a></span>+<a id="r4"></a>+All space leak degrades performance, and production-quality programs should eradicate as much leak behaviour as <span>possible. <a href="#4">[4]</a></span> Difficulty ranges from distracting (minutes) to formidable (days, or worse). This steers development resources away from the application domain, forcing one to resort to bag-of-tricks hackery in attempting to isolate and resolve the more serious leaks as they arise.-Understanding what's going on requires thinking about memory at a low level, and the abstractions involved are more complex than traditional block allocation.+Understanding what’s going on requires thinking about memory at a low level, and the abstractions involved are more complex than traditional block allocation. For space leak debugging, the current best practises constitute a black art. Leak behaviour is also extremely sensitive to build configuration (compiler version, and flags such as optimisation level). </div>@@ -79,7 +79,7 @@ <h3>I heard Haskell will be strict-by-default in future...</h3> -Nah. ;) But if it were, you'd then have complementary problems, of overly strict code hurting performance.+Nah. ;) But if it were, you’d then have complementary problems, of overly strict code hurting performance. Making the language implicitly strict is not a panacea (though a pragma to that effect would be welcome; also consider <a href="http://hackage.haskell.org/package/strict-ghc-plugin">strict-ghc-plugin</a> and <a href="http://hackage.haskell.org/package/seqaid">seqaid</a>). <p>@@ -89,7 +89,7 @@ through an improved understanding of demand, strictness, and evaluation. The optimal solution will often be a complex fusion of lazy and strict. As better tools emerge, these judgements will be automated, meaning less disruption to your development objectives.-You'll enjoy more sustained attention on your domain of <span>interest! <a href="#5">[5]</a></span>+You’ll enjoy more sustained attention on your domain of <span>interest! <a href="#5">[5]</a></span> <h3>Show me a simple example of a program that leaks</h3> @@ -212,7 +212,7 @@ #if STATS -- XXX This doesn't work! -- Please GHC-compile with -rtsopts -with-rtsopts=-s -with-rtsopts=-T--- (-s not -T are independent; nice to see -s summary info.)+-- (-s and -T are independent; nice to see -s summary info.) {-# OPTIONS_GHC -rtsopts #-} {- OPTIONS_GHC -with-rtsopts=-s #-} {-# OPTIONS_GHC -with-rtsopts=-T #-}@@ -353,14 +353,14 @@ <p> In a way this is not the fault of the programmer, but of the language or API. The programmer should not <em>have</em> to think too hard about whether a fold is strict or not.-All the programmer really wants is to receive timely output from the program as it's demanded.+All the programmer really wants is to receive timely output from the program as it’s demanded. The ideal language/implementation relieves as many concerns about the "how" as possible, letting the human focus on the "what". <p> <div class="digression" style="display: none;"> <div class="red"> I cannot seem to put my finger on the difference... Having that much trouble to find /anything/ to say that might differentiate space and memory leak is telling...-Of what though? That there is no difference? Or that I'm too ignorant to imagine it?...+Of what though? That there is no difference? Or that I’m too ignorant to imagine it?... </div> <p> This is a worst-case scenario:@@ -383,12 +383,6 @@ <h3 style="margin-top: 50px; margin-bottom: 8px;">Notes</h3> -<!--div class="red">-I've changed my mind (todo): Don't use links for [1] etc. here. The user will use their back button if they want to jump back. (Personally, I frequently scroll back up...). Instead, offer a caret at the END of the note. <a href=""><tt><b>^</b></tt></a>-<p>-Unfortunately, it looks like ass - it's so small it's hard to see the blue colour.-</div-->- <table> <tr id="1">@@ -396,9 +390,9 @@ [1] </td> <td>-Given the non-locality of space leak phenomena in lazy languages, it is usually more appropriate to speak of "space leak" as an holistic, abstract quality of a program, rather than to speak of "a space leak" in particular.-When I speak of "a leak", this refers to a particular leaking program as a whole, or to a particular run of a leaking program.-Sometimes we leave out the word "space" and just speak of "leak", since space leak is the dominant form of resource leak plaguing <span>Haskell. <a href="#r1">⇪</a></span>+Given the non-locality of space leak phenomena in lazy languages, it is usually more appropriate to speak of “space leak” as an holistic, abstract quality of a program, rather than to speak of “a space leak” in particular.+When I speak of “a leak”, this refers to a particular leaking program as a whole, or to a particular run of a leaking program.+Sometimes we leave out the word “space” and just speak of “leak”, since space leak is the dominant form of resource leak plaguing <span>Haskell. <a href="#r1">⇪</a></span> </td> </tr> @@ -418,7 +412,7 @@ [3] </td> <td>-One eventually enters the vast and nebulous realm of program optimisation, where the criterion "retains memory longer than expected" ramifies and <span>effervesces. <a href="#r3">⇪</a></span>+At least, the GHC implementation of Haskell is <span>lazy. <a href="#r3">⇪</a></span> </td> </tr> @@ -427,7 +421,7 @@ [4] </td> <td>-At least, the GHC implementation of Haskell is <span>lazy. <a href="#r4">⇪</a></span>+One eventually enters the vast and nebulous realm of program optimisation, where the criterion “retains memory longer than expected” ramifies and <span>effervesces. <a href="#r4">⇪</a></span> </td> </tr> @@ -437,7 +431,7 @@ </td> <td> Otherwise, your domain of interest slides gradually, out of necessity or frustration, towards programming language theory and implementation.-Not a bad thing of itself, but it's not entirely satisfying to have your goals deflected, even if the shift was toward the noble pursuit of better <span>tools. <a href="#r5">⇪</a></span>+Not a bad thing of itself, but it’s not entirely satisfying to have your goals deflected, even if the shift was toward the noble pursuit of better <span>tools. <a href="#r5">⇪</a></span> </td> </tr> @@ -446,7 +440,7 @@ [6] </td> <td>-For instance, Haskell's most famous space leak, <a href="http://blog.ezyang.com/2011/05/anatomy-of-a-thunk-leak">Anatomy of a Thunk Leak</a>, no longer leaks with GHC 7.8 and <span>-O2. <a href="#r6">⇪</a></span>+For instance, Haskell’s most famous space leak, <a href="http://blog.ezyang.com/2011/05/anatomy-of-a-thunk-leak">Anatomy of a Thunk Leak</a>, no longer leaks with GHC 7.8 and <span>-O2. <a href="#r6">⇪</a></span> </td> </tr> @@ -458,6 +452,10 @@ <ul> <li><a href="http://en.wikibooks.org/wiki/Haskell/Laziness"> Laziness</a>+<li><a href="http://en.wikibooks.org/wiki/Haskell/Strictness">+Strictness</a>+<li><a href="http://en.wikibooks.org/wiki/Haskell/Graph_reduction">+Graph reduction</a> <span style="font-size: 80%;">(good overall intro to these topics)</span> </ul> haskellwiki pages:@@ -467,9 +465,9 @@ <li><a href="https://www.haskell.org/haskellwiki/Performance/Space"> Space</a> <li><a href="https://www.haskell.org/haskellwiki/Performance/Laziness">-Laziness</a> (different than the above!)+Laziness</a> <span style="font-size: 80%;">(different than the above!)</span> <li><a href="https://www.haskell.org/haskellwiki/Performance/Strictness">-Strictness</a>+Strictness</a> <span style="font-size: 80%;">(ditto)</span> <li><a href="https://www.haskell.org/haskellwiki/How_to_profile_a_Haskell_program"> How to profile a Haskell program</a> <li><a href="https://www.haskell.org/haskellwiki/Performance/Accumulating_parameter">
HTML/output.html view
@@ -64,12 +64,12 @@ <ul> <li>You can see the space leak as a steady, substantial growth in the heap size, from <tt><em>N</em></tt> equal 0 through 5, and again in the first five pattern lines. <li>You can see the first large, strict blobs get hit at a depth of 5 (with <tt>forcen</tt>).-<li>Unfortunately :) it is not until a depth of 6 that the leak can be plugged. (Well, you can plug it without forcing the spine, using let-lifting, but <tt>seqaid</tt> doesn't do that yet.) So <tt>NFDataN</tt> is not a feasible solution for this leak.+<li>Unfortunately :) it is not until a depth of 6 that the leak can be plugged. (Well, you can plug it without forcing the spine, using let-lifting, but <tt>seqaid</tt> doesn’t do that yet.) So <tt>NFDataN</tt> is not a feasible solution for this leak. <li><tt>NFDataP.forcep</tt> successfully plugs the leak without hitting the big strict blobs.-<li>This output doesn't show how <tt>NFData</tt> would perform worse, but for large <tt><em>N</em></tt> there is additional penalty due to the presence of some long lists (not strict, but deep) in the state.+<li>This output doesn’t show how <tt>NFData</tt> would perform worse, but for large <tt><em>N</em></tt> there is additional penalty due to the presence of some long lists (not strict, but deep) in the state. <!--<li>It may appear there is still a slight leak in the heap, with the final pattern, but if the run is extended, this space is reclaimed periodically.-I don't quite understand this, since I am using <tt>performGC</tt> before each stats line is printed, but the fact is there is no longitudinal net growth.-(Oops, I don't see it in this paste anyways...).-->+I don’t quite understand this, since I am using <tt>performGC</tt> before each stats line is printed, but the fact is there is no longitudinal net growth.+(Oops, I don’t see it in this paste anyways...).--> </ul> <div class="footer">
changelog.txt view
@@ -1,4 +1,9 @@ +** 0.3.0.3 -> 0.4.0.0+ - deepseq-bounded major version bump again (OverloadedStrings! yummy)+ - there'll be two or three of these over the next month or so, then+ thing'll likely get pretty quiet+ 0.3.0.2 -> 0.3.0.3 - figured out a few tricks - hopefully this upload is the ticket; sorry for the extra version uploads
cpphs.sh view
@@ -13,7 +13,8 @@ # add an annotation). I could have been doing something # constructive with this time. -env PATH=$PATH:$HOME/.cabal/bin:.cabal-sandbox/bin:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs --cpp $*+# (Still not enough, if you build in the sandbox with multiple GHC versions?)+env PATH=./.cabal-sandbox/bin:$HOME/.cabal/bin:/home/builder/hackage-server/build-cache/tmp-install/bin:$PATH cpphs --cpp $* if [ 0 ]; then
deepseq-bounded-seqaid-leaky.html view
@@ -1,7 +1,7 @@ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head>-<title>Seqaid : Space leak diagnostic and remedial tool</title>+<title>ANN : deepseq-bounded, seqaid, leaky</title> <meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" /> <meta http-equiv="Pragma" content="no-cache" /> <meta http-equiv="Expires" content="0" />
leaky-full-incl-types.hs view
@@ -508,11 +508,11 @@ #if FORCING_STRATEGY == 0 state_ #elif FORCING_STRATEGY == 1- force $ state_+ force $ state_ #elif FORCING_STRATEGY == 2- forcen 6 $ state_+ forcen 6 $ state_ #elif FORCING_STRATEGY == 3- forcep_ pat $ state_+ forcep pat $ state_ #elif FORCING_STRATEGY == 4 seqaid state_ -- seqaid $ state_
leaky-full.hs view
@@ -464,11 +464,11 @@ #if FORCING_STRATEGY == 0 state_ #elif FORCING_STRATEGY == 1- force $ state_+ force $ state_ #elif FORCING_STRATEGY == 2- forcen 6 $ state_+ forcen 6 $ state_ #elif FORCING_STRATEGY == 3- forcep_ pat $ state_+ forcep pat $ state_ #elif FORCING_STRATEGY == 4 seqaid state_ -- seqaid $ state_
leaky-min.hs view
@@ -48,7 +48,7 @@ #if STATS -- XXX This doesn't work! -- Please GHC-compile with -rtsopts -with-rtsopts=-s -with-rtsopts=-T--- (-s not -T are independent; nice to see -s summary info.)+-- (-s and -T are independent; nice to see -s summary info.) {-# OPTIONS_GHC -rtsopts #-} {- OPTIONS_GHC -with-rtsopts=-s #-} {-# OPTIONS_GHC -with-rtsopts=-T #-}
leaky.cabal view
@@ -1,6 +1,8 @@ +-------------------------------------------------------------------------------+ name: leaky-version: 0.3.0.3+version: 0.4.0.0 synopsis: Robust space leak, and its strictification license: BSD3 license-file: LICENSE@@ -37,6 +39,8 @@ -- . -- NOTE: /Ignore the anonymous rogue failed build report below. If you examine the log it's clear that the problem is theirs, and nothing to do with this package or its dependencies. It's a shame this is so prominently displayed and impossible to remedy, it makes unbroken packages seem broken to visitors, and it exerts negative pressure on the use of cpphs and other build-tools./ +-------------------------------------------------------------------------------+ extra-source-files: README@@ -81,6 +85,8 @@ -- , Setup.hs --- , cabal.config +-------------------------------------------------------------------------------+ -- XXX Would be nice if could avoid the TH when FORCING_STRATEGY < 4. Flag HELLO_HACKAGE_VISITOR@@ -112,12 +118,6 @@ --Default: False Manual: True -Flag USING_SANDBOX- Description: I use them, but it's not default because it makes for much longer initial build, as all the dependencies (except base libs) need first to be installed into the sandbox.---Default: True- Default: False- Manual: True- Flag USE_SECOND_MODULE Description: Temporary for testing... (Later: Sadly this is not so temporary. There is some kind of interference between SOP.TH and Seqaid.TH splices which is still unresolved. So, types needing NFDataP (etc.) instances will need to live in a module which is /not/ being harnessed.) Default: True@@ -162,26 +162,16 @@ -- Sadly, not. -- See bottom of this file for the meanings of the values. --- This does indeed work for me (it is auto-toggled when cpphs is unavailable).--- Default to False, since it seems more likely there's a native cpp, than--- that a cpphs installation works smoothly.--- Later: Defaulting to True, since found some tricks...--- (Not even going to let this be manual:false anymore.) Flag USE_CPPHS- Description: Non-manual flag to allow the build system to try cpphs first, and if that fails, then to try system-wide cpp (typically GNU). I've actually toggled the default, so the build system will try for a system-wide cpp first, and failing that, will try to use cpphs, installing it if necessary. I prefer cpp. I am not getting my most invaluable -Wundef option with cpphs using -optP-Wundef -optP--cpp in my ghc-options. Does cpphs implement it? Not sure... / Back to default:true again...+ Description: The original intention was to make this a non-manual flag, to allow the build system to try cpphs first, and if that fails, then to try system-wide cpp (typically GNU). Due to path problems, when the build client installs cpphs in the course of installing, it turns out to be better to use a shell script to delegate which cpp runs, jimmy options, etc. --Default: False Default: True --Manual: False Manual: True --- Either Cowboy doesn't auto-toggle non-manual flags, or the error happens--- at too late a stage.--- Flag COWBOY--- Description: Non-manual flag to try to respond to rogue build failure reports from misconfigured auto-build systems.--- Default: False--- Manual: False+------------------------------------------------------------------------------- -executable leaky+executable leaky { main-is: leaky.hs --main-is: leaky-min.hs@@ -212,6 +202,22 @@ build-depends: cpphs > 1.14 + default-language: Haskell2010++ default-extensions: CPP++ ghc-options: -optP-Wundef -fno-warn-overlapping-patterns+--ghc-options: -optP-Wundef -fno-warn-overlapping-patterns -rtsopts -threaded++ if flag(PROFILE)+ ghc-options: -fprof-auto -auto-all -caf-all++ if flag(USE_CPPHS)+ -- the only reliable way to get equiv. of -pgmP"env PATH=$PATH:blah cpphs"+ ghc-options: -pgmP./cpphs.sh+--else+-- ghc-options: -cpp+ ---------- BEGIN SEQAID-SPECIFIC -- PART 1 of 2 ---------- -- User would need to add these deps themselves to their project .cabal.@@ -221,7 +227,7 @@ build-depends: - deepseq-bounded == 0.6.* || == 0.7.*+ deepseq-bounded >= 0.8 && < 1.0 , deepseq-generics == 0.1.* , generics-sop == 0.1.* , template-haskell@@ -229,9 +235,9 @@ -- XXX this is no good !! (co-evolving packages) -- I guess the best is to leave it unconstrained?...--- , seqaid == 0.3.0.0- , seqaid == 0.3.0.*--- , seqaid == 0.3.*+-- , seqaid == 0.4.0.0+ , seqaid == 0.4.0.*+-- , seqaid == 0.4.* -- Hopefully this will simply install the latest one, -- which ought to be fine: -- , seqaid@@ -245,85 +251,18 @@ ---------- END SEQAID-SPECIFIC -- PART 1 of 2 ---------- - default-language: Haskell2010-- default-extensions: CPP-- ghc-options: -optP-Wundef -fno-warn-overlapping-patterns---ghc-options: -optP-Wundef -fno-warn-overlapping-patterns -rtsopts -threaded-- if flag(PROFILE)- ghc-options: -fprof-auto -auto-all -caf-all---- You know what? Fuck it. fuckitfuckitfuckit--- Use a shell script delegator for this too.- -- !! This, in conjunction with the -pgmPenv -optP--cpp, WORKS.- -- (Can't we put the --cpp option on this one instead?)- -- Unfortunately, there seems to be no comparable trick for -pgmF.- -- (See comments below at -pgmF.)- -- -ags+ 20150202---cpp-options: PATH=$PATH:.cabal-sandbox/bin:$HOME/.cabal/bin:/home/builder/hackage-server/build-cache/tmp-install/bin:$HOME/_T03 cpphs---cpp-options: PATH=$PATH:.cabal-sandbox/bin:~/_T03:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs --cpp---cpp-options: PATH=$PATH:.cabal-sandbox/bin:$HOME/_T03:/home/andru/_T03:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs --cpp---cpp-options: PATH=.cabal-sandbox/bin:$HOME/_T03:/home/andru/_T03:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs --cpp---cpp-options: PATH=.cabal-sandbox/bin:/home/andru/_T03:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs --cpp---cpp-options: PATH=$PATH:.cabal-sandbox/bin:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs --cpp---cpp-options: PATH=$PATH:.cabal-sandbox/bin:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs---cpp-options: PATH=$PATH:.cabal-sandbox/bin:$HOME/.cabal/bin:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs---cpp-options: PATH=$PATH:~/.cabal/bin:.cabal-sandbox/bin:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs---cpp-options: PATH=$PATH:~/.cabal/bin:.cabal-sandbox/bin:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs --cpp-- if flag(USE_CPPHS)- -- -ags+ 20150202- ghc-options: -pgmP./cpphs.sh--- ghc-options: -pgmPenv--- ghc-options: -pgmPenv -optP--cpp--- target ‘PATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin\’ is not a module name or a source file--- ghc-options: -pgmPenv\ PATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin\ cpphs -optP--cpp--- target ‘PATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin\\’ is not a module name or a source file--- ghc-options: -pgmPenv\\ PATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin\\ cpphs -optP--cpp--- target ‘PATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin’ is not a module name or a source file--- ghc-options: -pgmP"env PATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs" -optP--cpp--- ghc-options: -pgmPenv -optPPATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin -optPcpphs -optP--cpp--- ghc-options: -pgmPenv -optP"PATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin" -optPcpphs -optP--cpp--- ghc-options: -pgmPenv -optP" PATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin cpphs --cpp"--- ghc-options: -pgmPcpphs -optP--cpp-----else---- ghc-options: -cpp- ---------- BEGIN SEQAID-SPECIFIC -- PART 2 of 2 ---------- if flag(TURN_ON_SEQAID_PLUGIN) ghc-options: -fplugin=Seqaid.Plugin - -- Unfortunately, there seems to be no trick comparable to my -pgmP- -- hack above, not for -pgmF. :( The trouble is, the name of the file- -- being processed is always the first argument (see cabal build -v3),- -- which ruins the hack. Will continue to look for a workaround.- --- -- Specifically, quoting the GHC 7.8.4 docs:- -- "Use -pgmF cmd to select the program to use as the preprocessor. When invoked, the cmd pre-processor is given at least three arguments on its command-line: the first argument is the name of the original source file, the second is the name of the file holding the input, and the third is the name of the file where cmd should write its output to."- -- "Additional arguments to the pre-processor can be passed in using the -optF option. These are fed to cmd on the command line after the three standard input and output arguments."- --- -- I wonder if I put a file.sh script in the top-level dir of- -- my source distribution, if I could call that without worrying- -- about local paths? Then it could delegate to env, with the- -- arguments reordered as needed...- --- -- AND IT WORKED!!! I checked, and the seqaidpp.sh script MUST- -- have user execute permissions, which may be a problem (will- -- have to see).- --- -- It's just possible xargs could be used instead, and give us- -- argument reordering...- if flag(USING_SANDBOX)- ghc-options: -F -pgmF.cabal-sandbox/bin/seqaidpp- else- ghc-options: -F -pgmF./seqaidpp.sh--- ghc-options: -F -pgmFenv -optFPATH=$PATH:.cabal-sandbox/bin:/home/builder/hackage-server/build-cache/tmp-install/bin -optFseqaidpp--- ghc-options: -F -pgmFseqaidpp+ -- Cabal is just too much hassle to manage things like+ -- extending $PATH, so we use an delegator script.+ -- (Motivated by rogue anonymous failed build reports+ -- which Hackage makes it impossible to address except+ -- by adapting to the misconfiguration.)+ ghc-options: -F -pgmF./seqaidpp.sh if flag(OMNITYPIC) ghc-options: -optFomnitypic@@ -416,14 +355,7 @@ --ghc-options: -ddump-simpl --ghc-options: -ddump-splices ------------------------------------------------------------- Trying to get the -D options to come AFTER these ones...----- Sadly this did not seem to affect the GHC (re)ordering of -optP's----- and other cpp-options.----- SAY... cpp-options, right... wow...---if flag(USE_CPPHS)--- ghc-options: -pgmPenv -optPPATH=$PATH:/home/builder/hackage-server/build-cache/tmp-install/bin -optPcpphs -optP--cpp+} -------------------------------------------------------+-------------------------------------------------------------------------------
leaky.hs view
@@ -464,11 +464,11 @@ #if FORCING_STRATEGY == 0 state_ #elif FORCING_STRATEGY == 1- force $ state_+ force $ state_ #elif FORCING_STRATEGY == 2- forcen 6 $ state_+ forcen 6 $ state_ #elif FORCING_STRATEGY == 3- forcep_ pat $ state_+ forcep pat $ state_ #elif FORCING_STRATEGY == 4 seqaid state_ -- seqaid $ state_
seqaidpp.sh view
@@ -13,5 +13,6 @@ # add an annotation). I could have been doing something # constructive with this time. -env PATH=$PATH:$HOME/.cabal/bin:.cabal-sandbox/bin:/home/builder/hackage-server/build-cache/tmp-install/bin seqaidpp $*+# (Still not enough, if you build in the sandbox with multiple GHC versions?)+env PATH=./.cabal-sandbox/bin:$HOME/.cabal/bin:/home/builder/hackage-server/build-cache/tmp-install/bin:$PATH seqaidpp $*