On 24 January 2011 17:20, Jane Ren j2...@ucsd.edu wrote:
When I try this, I get
AstWalker: panic! (the 'impossible' happened)
(GHC version 7.0.1 for x86_64-apple-darwin):
lexical error at character 'i'
It looks like you need to add the CPP extension to the DynFlags:
On Mon, Jan 10, 2011 at 06:22:03PM -0600, David Peixotto wrote:
Another possible advantage to git would be its support for submodules[1]. If
we made the switch to git for all the repositories that GHC uses, then we
could set them up as submodules. The advantage of submodules is that the GHC
On 25 January 2011 09:35, Lars Viklund z...@acc.umu.se wrote:
A subtree seems to be a way of getting the
contents of a branch merged at a non-root location. It might be a
relevant read and something to evaluate.
There is also the git-subtree project
(https://github.com/apenwarr/git-subtree).
My guess is that the base-package modules need language extensions to compile.
These extensions are specified in libraries/base/base.cabal (search for
extensions). I don't think you are including these extensions in the dflags
you are using.
Personally I think it'd be better if each
On 21/01/2011 13:12, Ian Lynagh wrote:
On Fri, Jan 21, 2011 at 10:18:57AM +, Simon Marlow wrote:
On 20/01/2011 20:22, Axel Simon wrote:
So, again, for this particular extension I suggest that the layout
rule in the standard(s) should be revised -- if I'm mistaken, this will
not break
in ghci:
Prelude import Numeric.Units.Dimensional.Prelude as D
Prelude Numeric.Units.Dimensional.Prelude D.sqrt $ let s = 9 *~ (meter D.*
meter) in s
3.0 m
Prelude Numeric.Units.Dimensional.Prelude D.sqrt $ 9 *~ (meter D.* meter)
ghci hangs.
complied and optimized code detects loop and
Thanks for the report Pavel! Indeed strange. I don't have GHC 7.0.1
installed but definitely don't see this with 6.12.3. Did you put in a
GHC bug report at http://hackage.haskell.org/trac/ghc/wiki/ReportABug?
If not I'll do it tomorrow.
As a work-around you could try providing an explicit type
There is a weird type-checking bug in 7.0.1 that causes loopy behavior:
http://hackage.haskell.org/trac/ghc/ticket/4809
Not sure if that is what is happening to you or not. Though in my
experience it did not actually print loop, it just hung.
- jeremy
On Jan 25, 2011, at 10:48 AM, Pavel
It is NOT type checking bug. It causes Rec {} in core and _|_ in runtime :)
On 25.01.2011, at 22:35, Jeremy Shaw wrote:
There is a weird type-checking bug in 7.0.1 that causes loopy behavior:
http://hackage.haskell.org/trac/ghc/ticket/4809
Not sure if that is what is happening to you or
Hi, Jeremy. Probably I didn't read your message carefully enough. Sorry for
that.
In my case there's no recursive code sqrt calls nroot that calls Prelude.nroot
and Prelude./. Does that qualify?
pavel
On 25.01.2011, at 22:35, Jeremy Shaw wrote:
There is a weird type-checking bug in
10 matches
Mail list logo
