2008/12/12 Duncan Coutts :
> Let's see what David thinks. If he thinks is possible to fix these kinds
> of things where haddock is not covering the whole GHC AST (at least to
> the degree where it can ignore bits it does not understand). If that's
> not realistic in the short term then we probably
2008/12/12 Sean Leather :
> On Fri, Dec 12, 2008 at 13:22, Thomas Schilling wrote:
>>
>> The fromJust error is a bug, of course, however, the underlying
>> problem is a bit more difficult:
>>
>> Haddock doesn't generate any code, it only typechecks. If the code
>> uses Template Haskell, however, t
On Fri, Dec 12, 2008 at 13:22, Thomas Schilling wrote:
> The fromJust error is a bug, of course, however, the underlying
> problem is a bit more difficult:
>
> Haddock doesn't generate any code, it only typechecks. If the code
> uses Template Haskell, however, the typechecker will have to run
> H
The fromJust error is a bug, of course, however, the underlying
problem is a bit more difficult:
Haddock doesn't generate any code, it only typechecks. If the code
uses Template Haskell, however, the typechecker will have to run
Haskell code and potentially this code will have to come from a modu
> > I've been using "cabal haddock" to run haddock on my package. I also
>> > get the same error using haddock directly:
>> >
>> > > $ haddock -odir=tmp --debug --verbose --html
>> > Generics/EMGM.hs
>> > > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing
>>
>> Have you filed a ticke
> > I've been using "cabal haddock" to run haddock on my package. I also
> > get the same error using haddock directly:
> >
> > > $ haddock -odir=tmp --debug --verbose --html
> > Generics/EMGM.hs
> > > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing
>
> Have you filed a ticket for t
> > > Call the original haddockHook with the updated flags rather
> > > than the
> > > haddock command.
>
> main = defaultMainWithHooks simpleUserHooks {
> haddockHook = \pkg lbi h f ->
> let progs = userSpecifyArgs "haddock" ["--optghc=-D__HADDOCK__"]
>
On Fri, 2008-12-12 at 01:01 +, Duncan Coutts wrote:
> On Fri, 2008-12-12 at 01:01 +0100, Sean Leather wrote:
> >
> > Call the original haddockHook with the updated flags rather
> > than the
> > haddock command.
>
> > No change in output.
>
> Ah, sorry I misread the co
On Fri, 2008-12-12 at 01:01 +0100, Sean Leather wrote:
>
> Call the original haddockHook with the updated flags rather
> than the
> haddock command.
> No change in output.
Ah, sorry I misread the code. This works:
import Distribution.Simple
import Distribution.Simple.Loc
On Fri, 2008-12-12 at 00:19 +, Claus Reinke wrote:
> > Still, you might find something useful in the discussion for this ticket:
> >
> >Cabal should support Cabal-version-dependent Setup.hs
> >http://hackage.haskell.org/trac/hackage/ticket/326
>
> or, more directly:
>
> http://www.ha
Still, you might find something useful in the discussion for this ticket:
Cabal should support Cabal-version-dependent Setup.hs
http://hackage.haskell.org/trac/hackage/ticket/326
or, more directly:
http://www.haskell.org/pipermail/cabal-devel/2008-August/003576.html
so, if you add the h
> Let's suppose that I do actually want to define __HADDOCK__ for my library.
>> Can I do this with a user-defined hook using the Cabal library?
>>
>
> You might want to define it conditionally, depending on version.
>
I certainly might!
Cabal supports package-version macros, and haddock installs
> Call the original haddockHook with the updated flags rather than the
> haddock command.
-- Define CPP __HADDOCK__ macro when running haddock.
haddockHook' p l h f =
do putStrLn ("f=\"" ++ show f ++ "\"")
putStrLn ("g=\"" ++ show g ++ "\"")
*haddockHook* simpleUserHooks p l h g
whe
I would be happy to work around it if I could, but I can't. As far as I can
tell, I can't pass any flags to Haddock via the Cabal file. I would love to
tell Hackage to run Haddock like so, "cabal haddock
--haddock-option=--optghc=-D__HADDOCK__", but I don't know how.
Let's suppose that I do actu
On Fri, 2008-12-12 at 00:22 +0100, Sean Leather wrote:
> Let's suppose that I do actually want to define __HADDOCK__ for my
> library. Can I do this with a user-defined hook using the Cabal
> library?
>
> main :: IO ()
> main = defaultMainWithHooks hooks where
> hooks = simpleUserHooks { haddoc
Let's see what David thinks. If he thinks is possible to fix these kinds
of things where haddock is not covering the whole GHC AST (at least to
the degree where it can ignore bits it does not understand). If that's
not realistic in the short term then we probably should introduce some
haddock vers
> I would be happy to work around it if I could, but I can't. As far as I can
> tell, I can't pass any flags to Haddock via the Cabal file. I would love to
> tell Hackage to run Haddock like so, "cabal haddock
> --haddock-option=--optghc=-D__HADDOCK__", but I don't know how.
>
Let's suppose that I
On Thu, 2008-12-11 at 23:32 +0100, Sean Leather wrote:
>
> > That's quite a presumption there. I can certainly write a
> module that
> > compiles and produces documentation for Haddock but that is
> different
> > when compiled into binary form. Even without
On Thu, Dec 11, 2008 at 06:20:11PM +0100, Sean Leather wrote:
> Also, regarding transparency with Hackage: is it possible to determine
> exactly which tools (e.g. Haddock version) are being used on the server?
You can see which versions are used in the log of any failed build.
The docs aren't bui
> > That's quite a presumption there. I can certainly write a module that
> > compiles and produces documentation for Haddock but that is different
> > when compiled into binary form. Even without this particular problem,
> > I can see that being potentially useful.
>
> Sure, but it'd have to be a
On Thu, 2008-12-11 at 18:20 +0100, Sean Leather wrote:
>
> For haddock-0.x, Cabal cpp's all the modules with
> -D__HADDOCK__ because
> the old haddock cannot parse all sorts of things.
>
> However for haddock-2.x it is important not to use
> -D__HAD
> For haddock-0.x, Cabal cpp's all the modules with -D__HADDOCK__ because
> the old haddock cannot parse all sorts of things.
>
> However for haddock-2.x it is important not to use -D__HADDOCK__ because
> the hacks that people added for haddock-0.x would make haddock-2.x fail.
> For example they'd
On Thu, 2008-12-11 at 16:26 +0100, Sean Leather wrote:
>
> The above is true, but then I ran it with --optghc=-D__HADDOCK__ and
> that fixed the problem. You see, I didn't know who was actually
> defining the __HADDOCK__ macro. Now, after looking at code for Haddock
> and Cabal, I realize it's Ca
> > Now, I'm trying to use #ifndef __HADDOCK__ / #endif around those same
> > modules, and I'm still running into the same internal Haddock error:
> >
> > > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing
> >
> > I've been using "cabal haddock" to run haddock on my package. I also
>
On Thu, 2008-12-11 at 11:29 +0100, Sean Leather wrote:
> Now, I'm trying to use #ifndef __HADDOCK__ / #endif around those same
> modules, and I'm still running into the same internal Haddock error:
>
> > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing
>
> I've been using "cabal h
> > Suppose that I wanted to generate documentation for everything in my
> > Cabal package except for the modules with Template Haskell in them. Is
> > it enough to add {-# OPTIONS_HADDOCK hide #-} to each of these
> > modules? I tried, but it didn't pan out like I hoped. I'm still
> > getting the
On Wed, 2008-12-10 at 15:30 +0100, Sean Leather wrote:
> [Responding to an old (but still relevant) thread...]
>
> I'm getting this error as well, both in 2.3.0 and 2.4.1.
>
> Suppose that I wanted to generate documentation for everything in my
> Cabal package except for the modules with Template
[Responding to an old (but still relevant) thread...]
I'm getting this error as well, both in 2.3.0 and 2.4.1.
Suppose that I wanted to generate documentation for everything in my Cabal
package except for the modules with Template Haskell in them. Is it enough
to add {-# OPTIONS_HADDOCK hide #-}
I think this is a bug in Haddock related to template-haskell
declarations. It will hopefully be fixed soon, but I'm afraid it won't
part of the 2.3.0 version that will come with GHC 6.10.1.
David
2008/10/27 Leonidas Fegaras <[EMAIL PROTECTED]>:
>
> Sorry for the previous message. I am sending it
Sorry for the previous message. I am sending it again.
Dear fellow haskell programmers,
I tried to install a package in hackageDB and got a strange error from
haddock:
haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing
30 matches
Mail list logo
