I can get this to work if I compile it with ghc, rather than try to
run it with ghci or hugs.
ghc --make Alpha3D.hs
./Alpha3D
works fine with no hangs.
Deborah
On Dec 1, 2006, at 6:49 PM, Deborah Goldsmith wrote:
It fails on PowerPC too, using the standard PPC distribution.
Deborah
On De
It fails on PowerPC too, using the standard PPC distribution.
Deborah
On Dec 1, 2006, at 6:41 PM, Deborah Goldsmith wrote:
This also fails in Hugs (crashes rather than hangs), so it looks
like it's a problem with the GLUT binding on Mac OS X Intel rather
than something specific to GHC. I'll
This also fails in Hugs (crashes rather than hangs), so it looks like
it's a problem with the GLUT binding on Mac OS X Intel rather than
something specific to GHC. I'll see if I can find a PPC machine to
try it on also.
Deborah
On Dec 1, 2006, at 5:13 PM, Deborah Goldsmith wrote:
I can re
I can reproduce this with ghc-6.6 built from source as well. I
sampled ghc while it was stuck like this, and it looks like it's
trying to open a GUI event loop (not surprising if it's opening a
window). It looks like something about that is not working.
Unfortunately, the Intel binary distr
This is not the exact answer to your question, but if the first line
of your .hs file is
{-# OPTIONS_GHC -fglasgow-exts #-}
then GHC extensions will be enabled within the file, whether compiled,
loaded in GHCi, or run with runghc. Other compilers should ignore the
pragma (unlike the older {# OP
I need to pass -fglasgow-exts to runghc. It appears that if the first
flag to runghc is -f, it treats it as a path to GHC itself. So, I
cannot do the following:
runghc -fglasgow-exts Test.hs
because runghc failes (it says it can't find glasgow-exts). However if
I do this:
runghc -fc:/ghc/bin
Well, it doesn't lock the whole machine but loading Alpha3D.hs int
GHCi and typing main causes a window to be displayed with no content
and ghc 6.6 locked up, requiring a hard kill.
On 12/1/06, Sven Panne <[EMAIL PROTECTED]> wrote:
Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones:
> [...]
GHC 6.4.1 accepts your declaration but generates a useless insatance decl.
GHC 6.6 will still let you generate the same instance, but only if you use
another type variable, for instance
deriving (MonadReader x)
GHC 6.6's behaviour is defined by the appropriate section of the user manu
The NeHe tutorials work for me with both GHC 6.6 and HEAD on my Intel
Mac; however, I'm not using MacPorts.
Is anyone else here who uses MacPorts on an Intel Mac, to confirm or
deny the bug?
Cheers,
Wolfgang
___
Glasgow-haskell-users mailing list
G
Am Mittwoch, 29. November 2006 19:29 schrieb Joe Jones:
> [...] Anyone know of any issues with the current HOpenGL on Intel? [...]
The Haskell versions of the NeHe tutorials work for me on x86_64 openSUSE 10.1
(GHC 6.6 and bleeding edge GHC from darcs repo, perhaps a few weeks old), so
I guess t
when performing strictness/abscence/one-shot analysis, are rule bodies
taken into account?
No.
like, would the following cause trouble making const
no longer absent in its second argument?
const x y = x
{-# RULE "const/seq" forall a b . const a b = seq b a #-}
by trouble I mean the compile
11 matches
Mail list logo
