[ghci] fails silently if there are lines beginning with #

[idontgetoutmuch]

I am writing a blog on Haskell Vs C for performance and am including the C files

Comparison C Code
=================

Main
----

This is an example of C.

~~~~ {.c include="Chap1a.c"}
~~~~

Matrix
------

~~~~ {.c include="libc/Matrix.c"}
~~~~

Bibliography
============

And I then do e.g.

~/Library/Haskell/ghc-7.6.2/lib/pandoc-1.12.2.1/bin/pandoc -s Chap1.lhs --filter=./Include -t markdown+lhs > Chap1Expanded.lhs
~/Library/Haskell/ghc-7.6.2/lib/BlogLiterately-diagrams-0.1.3/bin/BlogLiteratelyD Chap1Expanded.lhs --math=mathjax --ghci > Chap1.html

This works fine apart from syntax highlighting for C but when I try to use [ghci] then I think the fact that the included C file contains # causes whatever calls ghci to fail silently (or perhaps ghci fails and the return is silent)

~~~~ {.c include="Chap1a.c"}
#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
#include "Matrix.h"
#include "Timing.h"

double mkBoundaryMask (int width, int height, int x, int y)

Any ideas on a workround would be appreciated.

[byorgey]

I'm going to need a bit more info to be able to track this down (I see no reason why C blocks should interact with the ghci feature at all). Could you provide a test file containing [ghci] which works as expected, but fails to work when adding a block of C code? Or at the very least, a complete example file which does not give the expected results (with a description of the flags used and expected/actual results).

[idontgetoutmuch]

With following (substitute ~ for tilde)

This is a test.

> foo = 2 + 3

tilde tilde tilde tilde {.c}
#include <stdio.h>

int main(void)
{
    printf("Hello, world!\n");
    return 0;
}
tilde tilde tilde tilde

What is the value of foo?

    [ghci]
    foo

I get

<p>What is the value of foo?</p>
<pre><code><span style="color: gray;">ghci&gt; </span>foo</code></pre>
<div class="references">

</div>

If I indent

#include <stdio.h>

by one space I get

<p>What is the value of foo?</p>
<pre><code><span style="color: gray;">ghci&gt; </span>foo
  5
</code></pre>
<div class="references">

</div>

so somehow the # on the first line is causing a problem,

[idontgetoutmuch]

Did you want me to create a gist or are you ok to copy and paste the code block above? Let me know which is more convenient for you? Thanks for looking into this.

[byorgey]

Thanks, this is perfect. No need to create a gist.

[byorgey]

OK, I see what the problem is. To implement the [ghci] feature, the entire file gets loaded into ghci. However, GHC's lhs parser fails when a line begins with # (I'm not sure why). I will have to think a bit about a good workaround.

[idontgetoutmuch]

Obviously while I'd be very happy with a workaround, shouldn't we also ask the ghc guys why ghci has a problem with # in the first column? I'm happy to do that.

Also I can manually workaround the situation by moving the # into the second column and then editing the html afterwards. Not very satisfactory but I only have to do it when I upload a blog post.

[idontgetoutmuch]

Perhaps we should close this since it really is a ghci issue:

https://ghc.haskell.org/trac/ghc/ticket/4836

[byorgey]

See https://ghc.haskell.org/trac/ghc/ticket/4836 .

[idontgetoutmuch]

:-) - I may try and work on this at the next Zurihac

[byorgey]

No, let's leave it open. Even if it is a ghci problem at root, it still makes sense to implement a workaround in BlogLiterately. (I doubt ghci will be fixed anytime soon.)

[byorgey]

As for a workaround, I think the best option is to create a temporary file which is the same as the input file but with lines beginning with # stripped, and give that as input to ghci instead. A bit of a hack, but then again BlogLiterately's ghci feature is one giant hack already ;-).

[byorgey]

Uploaded as BlogLiterately-0.7.1.4. Can you confirm that this workaround fixes your issue?

[idontgetoutmuch]

Fixed! Thanks very much :-)