seqaid 0.3.0.1 → 0.4.0.0
raw patch · 9 files changed
+71/−90 lines, 9 filesdep ~deepseq-bounded
Dependency ranges changed: deepseq-bounded
Files
- HTML/extra.html +18/−18
- HTML/extra2.html +6/−6
- HTML/seqaid.html +25/−24
- Seqaid/Runtime.hs +7/−4
- Seqaid/TH.hs +1/−1
- changelog.txt +5/−0
- cpphs.sh +2/−1
- deepseq-bounded-seqaid-leaky.html +1/−1
- seqaid.cabal +6/−35
HTML/extra.html view
@@ -18,15 +18,15 @@ Some words may be in order about where <tt>seqaid</tt> and <tt>leaky</tt> came from, and how this all fits together. <tt>seqaid</tt> was the first of this group of projects, started in June (2014).-At that time, it was a GHC API application, and there's been a fair amount of water under the bridge since then.+At that time, it was a GHC API application, and there’s been a fair amount of water under the bridge since then. In July I conceived of <tt><span class="nowrap">deepseq-bounded</span></tt> based on considerations while pushing <tt>seqaid</tt>. August I was on hiatus, then finished <tt><span class="nowrap">deepseq-bounded</span></tt>, but wanted to see if I could plug it in to <tt>seqaid</tt> and maybe release them together. <p>-Up till then, I'd been using <tt>Anatomy</tt> as my main space leak example, but it stopped leaking in GHC 7.8.1 (if not earlier).+Up till then, I’d been using <tt>Anatomy</tt> as my main space leak example, but it stopped leaking in GHC 7.8.1 (if not earlier). <!-- hide/show-I was also unaccountably unable to get it to leak for me anymore with GHC 7.6.3, and I still don't understand...-(It's <em>not</em> a path problem this time!)+I was also unaccountably unable to get it to leak for me anymore with GHC 7.6.3, and I still don’t understand...+(It’s <em>not</em> a path problem this time!) --> I needed a good, robust space leak example to test my work on. @@ -34,13 +34,13 @@ At the same time, I was dissatisfied with <tt>seqaid</tt> as a GHC API executable, because I wanted something more seamless to the user, like GHC plugins. So I foolishly went down a very deep rabbit hole to re-write <tt>seqaid</tt> as a GHC plugin, which finally was only possible by also using Template Haskell <em>and</em> a text-level (regex) pre-processor (GHC -F option). It is seamless to the user, but the code is quite a bit less elegant than the GHC API executable.-(Which wasn't elegant to begin with.)+(Which wasn’t elegant to begin with.) <!-- hide/show-In retrospect I should have spent that effort making the GHC API executable work as a stand-in for GHC, so in your project .cabal file you'd specify seqaid as an alternative compiler.+In retrospect I should have spent that effort making the GHC API executable work as a stand-in for GHC, so in your project .cabal file you’d specify seqaid as an alternative compiler. Oh well. Probably discussion will help decide the best future course. -->-I don't regret learning TH and Core, and the several other things learned on this adventure.+I don’t regret learning TH and Core, and the several other things learned on this adventure. But I would not recommend programming in Core unless you really need to, or you know (really know) that what you need to do is well-supported that late in the compilation pipeline. <p>@@ -49,14 +49,14 @@ I guess that was September. September/October was a bit disrupted, as I moved across the country, but then had a funeral to return for. -->-What I did was take my most recent GHC (7.8.1), and try to write a small program that exhibited a space leak, because I didn't have a single small example, although I have numerous large ones. :)-I documented this process (I always keep a play-by-play text file with any project or subproject), but I won't review it now.-Suffice it to say, <tt>leaky</tt> was designed to "resemble a real-world program" (in the choice of data types, and in the "steady-state, long-running" behaviour, with state-to-state evolution).-I didn't rest until I had it leaking with GHC 7.8.1 under -O2, even with all strict fields in the data structures.+What I did was take my most recent GHC (7.8.1), and try to write a small program that exhibited a space leak, because I didn’t have a single small example, although I have numerous large ones. :)+I documented this process (I always keep a play-by-play text file with any project or subproject), but I won’t review it now.+Suffice it to say, <tt>leaky</tt> was designed to resemble a “real-world program”, in the choice of data types, and in the “steady-state, long-running” behaviour, with data accumulation/transmutation.+I didn’t rest until I had it leaking with GHC 7.8.1 under -O2, even with all strict fields in the data structures. (It still leaks in 7.8.4 and <a href="https://downloads.haskell.org/~ghc/7.10.1-rc1/">7.10.1-rc1</a>.) <p>-During that battle of wits with the compiler, I wasn't really thinking about <tt><span class="nowrap">deepseq-bounded</span></tt> or <tt>seqaid</tt>, so the leak example was not contrived with these tools in mind (although they already existed, particularly <tt><span class="nowrap">deepseq-bounded</span></tt> which was finished).+During that battle of wits with the compiler, I wasn’t really thinking about <tt><span class="nowrap">deepseq-bounded</span></tt> or <tt>seqaid</tt>, so the leak example was not contrived with these tools in mind (although they already existed, particularly <tt><span class="nowrap">deepseq-bounded</span></tt> which was finished). <p> Now that I had a leak example, I was ready to test my leak-plugging tools.@@ -69,9 +69,9 @@ <p> I think the example is valid (realistic), notwithstanding these contrivances.-There hasn't been time yet to put the new tools to work on my real projects.+There hasn’t been time yet to put the new tools to work on my real projects. <tt>seqaid</tt> in particular is just breaking out of its shell.-I'll be reporting progress as it becomes feasible.+I’ll be reporting progress as it becomes feasible. <p> The following shows the output of <tt>seqaid</tt> with <tt>leaky</tt>.@@ -117,12 +117,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">
HTML/extra2.html view
@@ -17,7 +17,7 @@ </h3> <p style="margin-top: 16px;">-Previously, using an older version of shrinkPat, it worked out more smoothly, as shown below; so the listing <span class="strikeout">above</span> [at <a href="extra.html">this</a> page] is rather longer [not anymore] and raises some questions I don't yet have answers for, but the net result is the same, and the comments <span class="strikeout">following</span> [at that link] are all still valid.+Previously, using an older version of shrinkPat, it worked out more smoothly, as shown below; so the listing <span class="strikeout">above</span> [at <a href="extra.html">this</a> page] is rather longer [not anymore] and raises some questions I don’t yet have answers for, but the net result is the same, and the comments <span class="strikeout">following</span> [at that link] are all still valid. <p> (Actually, the numbers have not worked out quite this way for a long time anyway; this portays results from pre-published versions...).@@ -52,9 +52,9 @@ P ((!(!)(((!).!(!))))!(!(!))) 190012 8748076 TA P ((!(!)(((!).!(!))))!(!(!))) 128232 8867404 TA </pre>-This seems like a usability regression, but the truth is, this is an extreme case, and normally '!' characters will be infrequent, and '.' characters (which do no forcing) will typically predominate amongst leaves of a pattern. Still, if going to prefer parens to braces, might like to reconsider '!' as it is visually too similar to a parenthesis. Some of these issues can be resolved by adding whitespace within the pattern strings (which is permitted). Also, much depends on fonts, and if colour of even greyscale is available this may be a non-issue.+This seems like a usability regression, but the truth is, this is an extreme case, and normally ‘!’ characters will be infrequent, and ‘.’ characters (which do no forcing) will typically predominate amongst leaves of a pattern. Still, if going to prefer parens to braces, might like to reconsider ‘!’ as it is visually too similar to a parenthesis. Some of these issues can be resolved by adding whitespace within the pattern strings (which is permitted). Also, much depends on fonts, and if colour of even greyscale is available this may be a non-issue. <p>-In fact, to show how beneficial vertical alignment is to the human perception, let's see the new output (more interesting initial sequence) with padding added by hand:+In fact, to show how beneficial vertical alignment is to the human perception, let’s see the new output (more interesting initial sequence) with padding added by hand: <pre> P . 232448 1776868 TA P ( ) 302720 1719280 TA@@ -82,7 +82,7 @@ ! ! ! . . . </pre>-And certainly, you don't produce ()'s!+And certainly, you don’t produce ()’s! <p> (Later: Even the above is wrong; discussed in <a href="http://www.fremissant.net/deepseq-bounded/deepseq-bounded.html#afterthoughts">afterthoughts</a> in the <tt>deepseq-bounded</tt> homepage.) <p>@@ -97,9 +97,9 @@ P <span style="color: #BBB;">(</span>(!(!)(((!).!(!))))!(!(!))<span style="color: #BBB;">)</span> 1925776 2392040 TA </pre> <p>-What the heck, I'll paste that <span class="strikeout">above</span>, although it is hand-padded...+What the heck, I’ll paste that <span class="strikeout">above</span>, although it is hand-padded... <p>-And here's what had in main document before the shrinkPat fix, as I don't have the heart to delete it yet. :)+And here’s what had in main document before the shrinkPat fix, as I don’t have the heart to delete it yet. :) <pre style="margin-bottom: 0px;"> live alloc type P . 232448 1776868 TA
HTML/seqaid.html view
@@ -15,10 +15,10 @@ <h2 style="margin-top: 50px; margin-bottom: 10px;">Seqaid</h2> <h3 style="margin-top: 12px; color: #666;">Space Leak Diagnostic and Remedial Tool</h3> -If you're reading this, you probably don't need to be told that <span class="nowrap">space leak is</span> the bane of lazy languages like Haskell.+If you’re reading this, you probably don’t need to be told that <span class="nowrap">space leak is</span> the bane of lazy languages like Haskell. <!-- http://neilmitchell.blogspot.ca/2013/11/acm-article-leaking-space.html -->-Quoting <span class="nowrap">briefly from</span> <span class="nowrap">Neil Mitchell's 2013</span> <a href="http://queue.acm.org/detail.cfm?id=2538488">article</a> in <em>ACM Queue</em>:+Quoting <span class="nowrap">briefly from</span> <span class="nowrap">Neil Mitchell’s 2013</span> <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;">@@ -50,7 +50,7 @@ <p> Seqaid can auto-plug many <span>leaks. <a href="#1">[1]</a></span>-<!--But there's still many it cannot help you with, at least without some coaxing on your part.-->+<!--But there’s still many it cannot help you with, at least without some coaxing on your part.--> However, not all leaks can be addressed by adding strictness; and, although most can (in my experience), usually these could also be addressed by refactoring in such a way that no added strictness was required. It may be that clues to such refactorings are offered by observation of optimal forcing patterns.@@ -59,22 +59,23 @@ I believe that seqaid has potential to be a useful resource, but this is only a bare-bones first-version. <a id="r2"></a>-The ultimate goal would be to see some evolution of this make it into compilers (perhaps even the GHC RTS), supposing a better solution hasn't arrived first.+The ultimate goal would be to see some evolution of this make it into compilers (perhaps even the GHC RTS), supposing a better solution hasn’t arrived first. <p> Seqaid is more general-purpose than just a space leak tool. It contains TH and GHC plugin code to <span>automatically <a href="#2">[2]</a></span> instrument Haskell packages with an arbitrary wrapper function around select expressions.-There's nothing (much) to stop you from substituting your own wrapper functions.+There’s nothing (much) to stop you from substituting your own wrapper functions. When the dust settles here, I should probably try to split off a wrapper-agnostic auto-instrumentation tool. <p>-We do not have the luxury of changing the types of the functions we're instrumenting, so passing extra state in any pure way is out of the question.+We do not have the luxury of changing the types of the functions we’re instrumenting, so passing extra state in any pure way is out of the question. In seqaid specifically, per-call-site data is maintained by judicious use of unsafe <tt>IORef</tt> operations. <!-- However, there are no safety implications in this case, as proven elsewhere. <a href="#3">[3]</a> --> The unsafe operations are no more dangerous than <tt>seq</tt> (no matter how wrong things go). <a id="r3"></a>-But it is true that, technically, program semantics can be affected by strictification — specifically, adding strictness to a program may introduce bottoms (in addition to any that might already be lurking).+But it is true that, technically, program semantics can be affected by strictification:+Adding strictness to a program may introduce bottoms (in addition to any that might already be lurking). <p> <a id="using"></a> Happily, although <tt>seq</tt> breaks free theorems, <span>seqaid does not. <a href="#3">[3]</a></span>@@ -92,13 +93,13 @@ Control.DeepSeq and related generics/TH modules are a great tool for debugging space leaks, and also a great temptation for evading them. A common strategy is to start at a high level in leaking code (in the sense of high in the parse tree), finding a place where a forcing function will squash your leaks, and then working the forcer further down until the offending code has been discovered.-For didactic purposes, let's suppose your forcing function is deepseq.+For didactic purposes, let’s suppose your forcing function is deepseq. Sometimes more than one site will have leaky code, so as the deepseq is moved down, it may have to be duplicated and branch out as well. <p> It would be nice to automate this process of refining the locations of deepseq. Something simple that should work is a binary partitioning of descendant expressions, into those which propagate the deepseq, and those which do not. Auto-recompilation and auto-profile-analysis can determine whether the change maintains leak-free behaviour, guiding the search for the smallest expressions which need forcing.-The developer may prefer to force at a higher level, in case this minimal set is highly ramified (high cardinality), but mostly we're interested in those expressions deepest in the parse tree that, forced, suffice to staunch the leak.+The developer may prefer to force at a higher level, in case this minimal set is highly ramified (high cardinality), but mostly we’re interested in those expressions deepest in the parse tree that, forced, suffice to staunch the leak. <p> @@ -158,8 +159,8 @@ <p> Manual instrumentation is also supported, should you prefer.-Simply wrap any expressions you'd like in harness with a <tt>seqaid</tt> application.-Although <tt>seqaid</tt> is not an actual function, from the user's perspective it must be treated as if it was, in the fixity/associativity context of each call site.+Simply wrap any expressions you’d like in harness with a <tt>seqaid</tt> application.+Although <tt>seqaid</tt> is not an actual function, from the user’s perspective it must be treated as if it was, in the fixity/associativity context of each call site. For technical reasons <span style="font-size: 80%">[no good reason really...]</span>, this presently also requires adding a <a href="http://hackage.haskell.org/package/seqaid/docs/Seqaid-Ann.html#t:SeqaidAnnManual"><tt>SeqaidAnnManual</tt></a> annotation for each bind you edit. <!--span style="font-size: 80%;">[That document is still not written, but <tt>leaky</tt> at <tt>FORCING_STRATEGY=4</tt> is a demonstation.]</span--> @@ -172,7 +173,7 @@ <a id="dig01s" class="dig-toggle-show" href='javascript:toggle("dig01");' style="margin-left: 20px;">Show</a> <div id="dig01" class="digression" style="margin-left: 20px;"> <a id="dig01h" style="margin-bottom: -15px;" class="dig-toggle-hide" href='javascript:toggle("dig01");'>Hide</a><p style="margin-bottom: 0px;">-I'm just fretting that I should have investigated using a GHC API app as a GHC replacement instead, if by chance it can be done light-weight.+I’m just fretting that I should have investigated using a GHC API app as a GHC replacement instead, if by chance it can be done light-weight. Well, at worst the GHC program is only a bit over 1 MB in size. Er ... but compiling it is a serious build, this is not like any old cabal install from hackage... But also, it seems GHC API can be used with TH.@@ -185,17 +186,17 @@ Unfortunately, auto-instrumentation turned out to be a nightmare, particularly as I had no TH or Core programming experience, setting me back by more than a month... <p>-So I've determined to release <a href="http://hackage.haskell.org/package/leaky">leaky</a>, <a href="http://hackage.haskell.org/package/deepseq-bounded"><span class="nowrap">deepseq-bounded</span></a>, and <a href="http://hackage.haskell.org/package/seqaid">seqaid</a> without further delay.+So I’ve determined to release <a href="http://hackage.haskell.org/package/leaky">leaky</a>, <a href="http://hackage.haskell.org/package/deepseq-bounded"><span class="nowrap">deepseq-bounded</span></a>, and <a href="http://hackage.haskell.org/package/seqaid">seqaid</a> without further delay. <p>-After a much-needed vacation from these topics (which are not my interest; I'm an applications programmer!...), there are a few more things I'm intending to do.+After a much-needed vacation from these topics (which are not my interest; I’m an applications programmer!...), there are a few more things I’m intending to do. <p> <a style="display: none;" id="dig02s" class="dig-toggle-show" href='javascript:toggle("dig02");'>Show</a> <div style="display: inline-block;" id="dig02" class="digression" style="margin: 20px 100px 0px 30px;"> <a style="display: block; margin-bottom: -15px;" id="dig02h" class="dig-toggle-hide" href='javascript:toggle("dig02");'>Hide</a><p style="margin-bottom: 0px;"> From this point on (including note <a href="#3">[3]</a>), I may be talking nonsense in places.<br />-I'll ammend this preliminary stuff subject to discussion and new learning.+I’ll ammend this preliminary stuff subject to discussion and new learning. </div> <h4>Immediate priorities</h4>@@ -214,7 +215,7 @@ <ul> <!-- <li>-Seqaid currently wraps whole RHS's of declarations.+Seqaid currently wraps whole RHS’s of declarations. This is ineffectual for monadic functions. Monadic functions can be manually instrumented by wrapping ("injecting at") subexpressions. Getting demand propagation right might be tricky.@@ -260,10 +261,10 @@ it is a virtual machine (mostly written in C) which evaluates your code, so implementing seqaid in the RTS will probably be quite a departure from the above. <p>-The new <tt>Seqable</tt> module of <tt><span class="nowrap">deepseq-bounded</span></tt> is a step in the right direction, but I've not had time to really investigate it let alone document it.+The new <tt>Seqable</tt> module of <tt><span class="nowrap">deepseq-bounded</span></tt> is a step in the right direction, but I’ve not had time to really investigate it let alone document it. <p>-And anyway, it turns out <tt>seq</tt> is completely desugared by the time it hits the simplifier, so we're dealing with Core <tt>let</tt> versus <tt>case</tt> antics, and not even function applications.+And anyway, it turns out <tt>seq</tt> is completely desugared by the time it hits the simplifier, so we’re dealing with Core <tt>let</tt> versus <tt>case</tt> antics, and not even function applications. <h3 style="margin-top: 50px; margin-bottom: 8px;">Notes</h3> @@ -294,20 +295,20 @@ <div id="dig05" class="digression" style="margin-left: 30px; margin-right: 100px; padding-bottom: 1px; margin-top: 10px;"> <a id="dig05h" style="margin-bottom: -15px;" class="dig-toggle-hide" href='javascript:toggle("dig05");' style="margin-bottom: 6px;">Hide</a><p style="margin-bottom: 0px;"> LATER: See writings in /work/Projects/MiniProjects/Metaboiler/000-readme.-I've looked into it, and basically, yes we can avoid ALMOST all user edits to intrumentation target source modules.-But if you have datatypes involved, and they don't have instances for Typeable, Data, and Generic, you will have to add these to the deriving clauses.+I’ve looked into it, and basically, yes we can avoid ALMOST all user edits to intrumentation target source modules.+But if you have datatypes involved, and they don’t have instances for Typeable, Data, and Generic, you will have to add these to the deriving clauses. <p> Or, better, add a single file importing all the types you need in instrumented code, and use -XStandaloneDeriving to "top them up" with instances. Then you only need to add this import to your instrumentation target source modules. And, as the preprocessor can inject imports, you need only provide the name as an argument to the preprocessor (or use a standard, fixed "Seqaid..." name), so actually STILL NO EDITS (excepting preprocessor) ARE NEEDED TO ANY ORIGINAL SOURCE FILES. Whew! It seems like there is always a way out... <p> All this is only needed for the <tt>deriveGeneric ''T</tt> for your types <tt>T</tt>.-But we cannot avoid the user having to add at least the "deriving instance" lines for their types, because TH cannot splice a "deriving instance" (-XStandaloneDeriving) to date (and TH cannot add/augment "deriving" clauses of existing types). [It looks like it's just coming down the pipes however.]+But we cannot avoid the user having to add at least the "deriving instance" lines for their types, because TH cannot splice a "deriving instance" (-XStandaloneDeriving) to date (and TH cannot add/augment "deriving" clauses of existing types). [It looks like it’s just coming down the pipes however.] <p> [Old sentences, used to be in body of document:] The TH and Core (plugin) code work in tandem to make this possible, with the addition of two lines of code to each module the user wants instrumented. And these two lines are both constants, and can safely be automatically inserted by an editing script.-(There's no way to do that with the GHC tools, that I know of. -F -pgmF -optF, but still isn't there some issue about temp files? I seem to recall from FreeSect...)+(There’s no way to do that with the GHC tools, that I know of. -F -pgmF -optF, but still isn’t there some issue about temp files? I seem to recall from FreeSect...) --> </div> </td>@@ -339,7 +340,7 @@ If performance tuning was your game, you could even turn the tide and use feedback from seqaid to search for optimising transformations... <p style="margin-bottom: 0px;"> In case you are somehow able to perform your transformations at runtime, even that is no problem.-You don't even need to turn off the plugin!+You don’t even need to turn off the plugin! The forcing harness can be made truly transparent <!-- (<em>i.e.</em> not a single <tt>seq</tt> introduced) --> by simply asking it, dynamically and selectively, to lay off while you <span>transform. <a href="#r3">⇪</a></span>@@ -355,7 +356,7 @@ <p> Another point to note about the seqaid preprocessor concerns inlining. GHC inlines very aggressively, even across module boundaries.-If you've requested instrumentation of bind <tt>duty</tt>, but somehow <tt>duty</tt> is inlined before the Core plugin runs, the expressions you hoped to harness will slip through the net.+If you’ve requested instrumentation of bind <tt>duty</tt>, but somehow <tt>duty</tt> is inlined before the Core plugin runs, the expressions you hoped to harness will slip through the net. If you can afford a complete (blanket) harness, this problem will never arise, as it has to be inlined <em>somewhere</em>! Another possible solution would be to have TH add a <tt>NOINLINE</tt> pragma to any binds mentioned in <tt>seqaid.config</tt>; but weakening the inlining powers of a functional language compiler is generally a bad idea — not just for the function call overhead: it blocks potential optimisations at the call site.
Seqaid/Runtime.hs view
@@ -275,10 +275,12 @@ #else pat' = pat x'' | stats_query_idx <= (1+max_depth)- = forcep_ pat x -- trying to use *n patterns instead+ = forcep pat x -- trying to use *n patterns instead+--- = forcep_ pat x -- deprecated function! -- = forcen depth x | otherwise- = forcep_ pat x+ = forcep pat x+--- = forcep_ pat x -- deprecated function! #endif #endif @@ -322,8 +324,9 @@ where --- !_ = trace t () t = show $ typeOf x- x' | t == "TA" = forcep_ fixed_pat x--- x' | t == "State" = forcep_ fixed_pat x+ x' | t == "TA" = forcep fixed_pat x+-- x' | t == "State" = forcep fixed_pat x+--- x' | t == "TA" = forcep_ fixed_pat x -- deprecated function! | otherwise = x #endif #endif
Seqaid/TH.hs view
@@ -1030,7 +1030,7 @@ -- This is to avoid duplication (perhaps ironically...): j p | ClassP n ts <- p = ClassP n $ map (substTyVars (orig,fresh)) ts | EqualP t1 t2 <- p = EqualP ((substTyVars (orig,fresh)) t1) ((substTyVars (orig,fresh)) t1)--- | EqualP t1 t2 <- p = error "make_ctx: not ready for EqualP"+--- | EqualP t1 t2 <- p = error "make_ctx: not ready for EqualP" ctx_ | isNothing mof = ctx | otherwise = map j ctx Just (orig,fresh) = mof -- antipattern...
changelog.txt view
@@ -1,4 +1,9 @@ +** 0.3.0.1 -> 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.0 -> 0.3.0.1 - still trying to decide on policy regarding cpphs - this is all motivated by one pesky rogue anonymous build spammer
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" />
seqaid.cabal view
@@ -2,7 +2,7 @@ ------------------------------------------------------------------------------- name: seqaid-version: 0.3.0.1+version: 0.4.0.0 synopsis: Dynamic strictness control, including space leak repair license: BSD3 license-file: LICENSE@@ -140,13 +140,8 @@ --Default: False Manual: True --- 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...+ 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@@ -243,7 +238,7 @@ build-depends: -- low-level forcing library- deepseq-bounded == 0.6.* || == 0.7.*+ deepseq-bounded >= 0.8 && < 1.0 -- ad hoc generics , syb <= 0.4.2@@ -299,19 +294,11 @@ ghc-options: -funbox-strict-fields -fwarn-tabs --ghc-options: -Wall - -- -ags+ 20150202---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)+ -- the only reliable way to get equiv. of -pgmP"env PATH=$PATH:blah cpphs" ghc-options: -pgmP./cpphs.sh- -- -ags+ 20150202--- ghc-options: -pgmPenv -optP--cpp--- ghc-options: -pgmPenv --else -- ghc-options: -cpp---ghc-options: -pgmP/usr/bin/cpp if flag(SAI_FORK) cpp-options: -DSAI_FORK=1@@ -418,19 +405,11 @@ ghc-options: -optP-Wundef -fno-warn-overlapping-patterns - -- -ags+ 20150202---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)+ -- the only reliable way to get equiv. of -pgmP"env PATH=$PATH:blah cpphs" ghc-options: -pgmP./cpphs.sh- -- -ags+ 20150202--- ghc-options: -pgmPenv -optP--cpp--- ghc-options: -pgmPenv --else -- ghc-options: -cpp---ghc-options: -pgmP/usr/bin/cpp -- Test #ifdef mingw32_HOST_OS instead! (it's built-in to GHC) ------@@ -488,19 +467,11 @@ ghc-options: -optP-Wundef -fno-warn-overlapping-patterns - -- -ags+ 20150202---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)+ -- the only reliable way to get equiv. of -pgmP"env PATH=$PATH:blah cpphs" ghc-options: -pgmP./cpphs.sh- -- -ags+ 20150202--- ghc-options: -pgmPenv -optP--cpp--- ghc-options: -pgmPenv --else -- ghc-options: -cpp---ghc-options: -pgmP/usr/bin/cpp if flag(USE_CPPHS) cpp-options: -DUSE_CPPHS=1