On Thu, 6 Aug 2009, Don Stewart wrote:
Someone please file a bug report,
http://hackage.haskell.org/trac/ghc/newticket?type=bug
Done, Don!
http://hackage.haskell.org/trac/ghc/ticket/3424
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
ht
On Thu, 6 Aug 2009, Dan Weston wrote:
Neil Mitchell wrote:
Hi
I think the issue you're running in to with 6.4 is this one:
http://hackage.haskell.org/trac/ghc/ticket/830 - known and fixed a
while back.
No, I am using the latest released ghc:
I think Neil refered to my experiences with GHC
felipe.lessa:
> On Thu, Aug 06, 2009 at 04:25:07PM -0700, Dan Weston wrote:
> > > ghc --version
> > The Glorious Glasgow Haskell Compilation System, version 6.10.4
>
> Confirmed on Gento amd64 with custom-built GHC from Haskell overlay:
>
> $ ghc --version
> The Glorious Glasgow Haskell Compilati
On Thu, Aug 06, 2009 at 04:25:07PM -0700, Dan Weston wrote:
> > ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.10.4
Confirmed on Gento amd64 with custom-built GHC from Haskell overlay:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.4
$ u
I should clarify that this was done on an older kernel (bootstrapped
from ghc 6.4 as Jeff Heard suggested), in case that makes any difference:
Main memory size: 7971 Mbytes
1 GenuineIntel Intel(R) Xeon(TM) CPU 3.40GHz processor
Swap Size: 2047 Mbytes
Num Processors: 1
Processor Type:
Yes, the GHC compiler will work on older kernels and CentOS kernels if
you bootstrap it with 6.4
On Thu, Aug 6, 2009 at 4:51 PM, Jason Dagit wrote:
>
>
> On Thu, Aug 6, 2009 at 1:39 PM, Henning Thielemann
> wrote:
>>
>> Today a student has shown me a program that consists of a large 'do' block
>>
No, I am using the latest released ghc:
> ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.4
[ z.hs is attached ]
> time ghc -O0 --make z.hs
[1 of 1] Compiling Main ( z.hs, z.o )
Linking z ...
14.422u 0.630s 0:15.10 99.6%0+0k 0+0io 0pf+0w
> time ./z
z
On Thu, 6 Aug 2009, Jason Dagit wrote:
'timer_create' problem. (At least, the 'cabal' executable that I
generated with a
GHC-6.8.2 had this problem when running on the cluster which reminded me
on the
problems with GHC-6.8 itself running on older Linux kernels.)
I just goo
On Thu, 6 Aug 2009, Dan Weston wrote:
I assume for the return line, you meant to return a list, not a tuple. ghc
doesn't support a 600-tuple.
Maybe that it was a list.
In any case, returning a list, I have verified that this problem exists in
ghc 6.10.3, for -O0 and -O2.
For -O0, it compi
Hi
I think the issue you're running in to with 6.4 is this one:
http://hackage.haskell.org/trac/ghc/ticket/830 - known and fixed a
while back.
Thanks
Neil
On Thu, Aug 6, 2009 at 9:59 PM, Dan Weston wrote:
> I assume for the return line, you meant to return a list, not a tuple. ghc
> doesn't sup
I assume for the return line, you meant to return a list, not a tuple.
ghc doesn't support a 600-tuple.
In any case, returning a list, I have verified that this problem exists
in ghc 6.10.3, for -O0 and -O2.
For -O0, it compiles and links fine, but gives this runtime message:
z: internal error
On Thu, Aug 6, 2009 at 1:39 PM, Henning Thielemann <
lemm...@henning-thielemann.de> wrote:
>
> Today a student has shown me a program that consists of a large 'do' block
> for the list monad. The program looks like
>
> do x1 <- [0..3]
> x2 <- [0..2]
> ...
> x600 <- [0..5]
> g
Today a student has shown me a program that consists of a large 'do'
block for the list monad. The program looks like
do x1 <- [0..3]
x2 <- [0..2]
...
x600 <- [0..5]
guard (x1+x2+2*x3 >= 0)
...
return (x1,x2,,x600)
It was actually generated by anothe
13 matches
Mail list logo
