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 i
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 o
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 <>, it just hung.
- jeremy
On Jan 25, 2011, at 10:48 AM, Pavel Perik
On 25.01.2011, at 18:37, Bjorn Buckwalter wrote:
> (I
> suspect the type inferencer is looping), but maybe you've figured out
> something workable for you already.
I told you I'm exhausted right now, didn't I? :) This is definitely not type
inferencer. The bug causes compiled program looping. A
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 sig
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 <> and let-tric
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 oth
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 base-pa
On 25 January 2011 09:35, Lars Viklund 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). They explain t
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 24 January 2011 17:20, Jane Ren 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:
setSessionDynFlags dflags
11 matches
Mail list logo
