On Sun, 2009-02-08 at 19:18 +0100, Andrea Vezzosi wrote:
> I did work on this and i simplified the code a lot fixing
> inconsistencies and making more explicit what how each component
> contributes to the arguments to haddock.
Much appreciated.
> Aside from this, should we also do the unliting an
I did work on this and i simplified the code a lot fixing
inconsistencies and making more explicit what how each component
contributes to the arguments to haddock.
Aside from this, should we also do the unliting and cpp from Cabal on
the sources passed to HsColour?
On Fri, Feb 6, 2009 at 11:27 PM,
2009/2/6 Duncan Coutts :
>
> Yes, against my better judgement the code in Cabal for haddock-2.x does
> not run cpp or unliting like it does for haddock-0.x. Instead it assumes
> that haddock-2.x will do all the cpp and unliting itself. Obviously this
> mean the special unliting mode that Cabal prov
On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote:
> 2009/2/6 Alistair Bayley :
> >>> [1 of 1] Compiling Test.Fail( Test\Fail.hs, Test\Fail.o )
> >>>
> >>> Test\Fail.hs:11:26:
> >>>Can't make a derived instance of `Typeable Fail'
> >>> (You need -XDeriveDataTypeable to derive an
2009/2/6 Alistair Bayley :
>>> [1 of 1] Compiling Test.Fail( Test\Fail.hs, Test\Fail.o )
>>>
>>> Test\Fail.hs:11:26:
>>>Can't make a derived instance of `Typeable Fail'
>>> (You need -XDeriveDataTypeable to derive an instance for this class)
>>>In the data type declaration for
>> [1 of 1] Compiling Test.Fail( Test\Fail.hs, Test\Fail.o )
>>
>> Test\Fail.hs:11:26:
>>Can't make a derived instance of `Typeable Fail'
>> (You need -XDeriveDataTypeable to derive an instance for this class)
>>In the data type declaration for `Fail'
>
> Are you processing the
2009/2/6 Alistair Bayley :
> I have this test case for Haddock (2.3.0):
>
> --
>
> |
> Module : Test.Haddock
> Copyright : (c) 2009 Alistair Bayley
> License : BSD-style
> Maintainer : alist...@abayley.org
> Stability : stable
> Por
