2008/12/12 Sean Leather leat...@cs.uu.nl:
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,
2008/12/12 Duncan Coutts duncan.cou...@worc.ox.ac.uk:
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
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__]
(withPrograms
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 this in the
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 this in the
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
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
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 same
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 haddock
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
get the same
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 Cabal.
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 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__HADDOCK__
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 different
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
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 this
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
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
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 { haddockHook
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
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
where
-- The
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 both
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
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:
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
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 code. This
[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 #-}
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
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
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
30 matches
Mail list logo
