- Glasgow-haskell-users

GHC 6.5 error? Illegal polymorphic or qualified type
by Rene de Visser 18 Apr '06

18 Apr '06

Hello, I tried to compile HAppS using the latest GHC snapshot (in compiles fine with 6.41). I for example get the error /home/rene/repos/HAppS/src/HAppS/MACID/Var.hs:23:0: Illegal polymorphic or qualified type: forall state event. Ev state event (ref t) In the type signature for `newEmptyRef': newEmptyRef :: (Monoid t, Ref ref) => AnyEv (ref t) Note that AnyEv is defined as type AnyEv a = forall state event. Ev state event a This should be OK shouldn't it? At least in works in 6.41 and everythis is quantified. Exactly what does the error message Illegal polymorphic or qualified type mean? Rene.

3 2

build log
by David Roundy 18 Apr '06

18 Apr '06

Hi all. Here's a build log from my bootstrap failure. -- David Roundy http://www.darcs.net

1 0

trouble bootstrapping ghc head
by David Roundy 18 Apr '06

18 Apr '06

Hi all, I'm getting the following error when bootstrapping the ghc head darcs repository: /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -i../compat -ignore-package Cabal -c ../compat/Distribution/Version.hs -o stage1/../compat/Distribution/Version.o -ohi stage1/../compat/Distribution/Version.hi ghc-6.4: error: directory portion of "stage1/../compat/Distribution/Version.o" does not exist (used with "-o" option.) <<ghc: 14201992 bytes, 3 GCs, 92408/92408 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.08 MUT (0.15 elapsed), 0.04 GC (0.04 elapsed) :ghc>> make[1]: *** [stage1/../compat/Distribution/Version.o] Error 1 make: *** [stage1] Error 1 I suspect this is related to the recent directory reorganization, but can't see whether it's something that I'm doing wrong or a makefile bug. -- David Roundy http://www.darcs.net

2 1

trouble bootstrapping ghc head
by David Roundy 18 Apr '06

18 Apr '06

Hi all, I'm getting the following error when bootstrapping the ghc head darcs repository: /usr/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -i../compat -ignore-package Cabal -c ../compat/Distribution/Version.hs -o stage1/../compat/Distribution/Version.o -ohi stage1/../compat/Distribution/Version.hi ghc-6.4: error: directory portion of "stage1/../compat/Distribution/Version.o" does not exist (used with "-o" option.) <<ghc: 14201992 bytes, 3 GCs, 92408/92408 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.08 MUT (0.15 elapsed), 0.04 GC (0.04 elapsed) :ghc>> make[1]: *** [stage1/../compat/Distribution/Version.o] Error 1 make: *** [stage1] Error 1 I suspect this is related to the recent directory reorganization, but can't see whether it's something that I'm doing wrong or a makefile bug. -- David Roundy

1 0

RE: FFI Bug - Finalizer always called with NULL pointer?
by Simon Peyton-Jones 15 Apr '06

15 Apr '06

Would you like to add to the GHC FAQ, or even start a "Hints about using the FFI" page? http://haskell.org/haskellwiki/GHC:Documentation (The section at the bottom called "collaborative documentation" is the place.) Hard-won experience like this should be captured. GHC's documentation is a Wiki specifically so that you can record it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Brian Hulley | Sent: 08 April 2006 10:35 | To: Brian Hulley; glasgow-haskell-users(a)haskell.org | Subject: Re: FFI Bug - Finalizer always called with NULL pointer? | | > [Helpful off-list suggestion to look at FFI spec for & more closely] | | Thanks. I'd read it several times before but hadn't understood the | difference between a function and the address of a function and so thought | '&' was optional, as it is in C for functions: | | void foo(); | | typedef void (*Fun)(); | | Fun a = &foo; | Fun b = foo; // same as above (in VC7) | | However I see now that in the Haskell FFI my original declaration, without | the &, was declaring duma_releaseFont to be a function taking no args and | returning a FunPtr, whereas with the &, I am declaring duma_releaseFont to | be the FunPtr itself. The '&' is needed because otherwise there would be no | way to distinguish the wrapping of a C function in a FunPtr and a C function | returning a FunPtr. | | So in a way it is "obvious" but only when it is realised that '&' actually | means something in Haskell FFI even though it is irrelevant (when taking | about functions) in C. | | Therefore there is no bug anywhere. It is just that FFI has a high learning | curve since it rests on extremely subtle but vital distinctions foreign to a | C programmer... :-) | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Optimization & Destructive Updates
by Lajos Nagy 14 Apr '06

14 Apr '06

I was just musing the other day about the possibility of allowing (efficient and transparent) destructive updates in certain situations. Take the following (giberish) example: f xs = g xs [] where g [] ac = ac g (x1:x2:xs) ac = g xs (ac ++ [x2,x1]) It seems to me that the list concatenation in the tail recursion call can be safely performed destructively. Does anybody know about any research going on in this area? (Mind you: no linear types, no monads, only `under the hood' compiler optimization.) I'm aware of the fact that this would imply another kind of overloading (destructive vs. non-destructive) for functions which also seems an interesting research area. Regards, -- Lajos Nagy Computer Science Ph.D. Student, Florida Institute of Technology

3 2

GHC and Cygwin/MinGW
by Rich Fought 14 Apr '06

14 Apr '06

Hello, I'm trying to port a linux-based Haskell application over to Win32. I am fiddling with both MinGW and Cygwin with varying degrees of bafflement. This is a server app that utilizes secure connections with the GnuTLS libraries. >From what I understand, the Win32 version of GHC targets MinGW. Does this mean that the GnuTLS libraries must be compiled for MinGW as well, or is it possible to link in cygwin libraries via the cygwin.dll somehow? Also, any ideas how difficult a Cygwin port of GHC would be? Tips would be much appreciated. Thanks, Rich

2 1

Possible runtime overhead of wrapping the IO monad?
by Brian Hulley 13 Apr '06

13 Apr '06

Hi, I'm designing an API for a simple graphics window, and am trying to make the correct usage of the API functions explicit and visible to the type system by using different monads which ultimately just wrap the IO monad. For example, in a callback for rendering stuff to the screen, only operations in the RenderM monad are allowed, and when specifying vertex info for a primitive, only VertexM operations are allowed. However I'm wondering if I can rely on all this monad stuff being optimized out at compile time. A sample monad is below: newtype VertexM a = VertexM (IO a) instance Monad VertexM where VertexM x >>= fry = VertexM $ do ax <- x let VertexM y = fry ax y return x = VertexM $ return x instance MonadIO VertexM where liftIO = VertexM The monad doesn't do anything interesting apart from allowing the type checker to reject programs that don't use the API the way it was intended (all these things you have to keep in your head in C programs), but I don't want to use it if I'm going to get a performance hit. Also, in: foreign import ccall duma_vertex3f :: Float -> Float -> Float -> IO () vertex3f :: Float -> Float -> Float -> VertexM () vertex3f x y z = liftIO $ duma_vertex3f x y z is there a penalty involved in calling vertex3f (from another module) or will the worker/wrapper optimization ensure that machine code in the other module just calls duma_vertex3f directly since the liftIO operation is just an irrelevance at the machine code level? So far I've just been using ghc --make and not bothering about what kind of code is generated. Is there a flag I can use to get ghc to output the stg code (or something higher level than just x86 machine code itself) so I can look at the output to see what optimizations are being done? Thanks, Brian.

5 10

Serious bug with ghc & FC5
by Alain Cremieux 13 Apr '06

13 Apr '06

(resent after being indefinitely held in fedora-haskell validation queue) Hi, 1) I have installed FC5 on 2 different machines. On my Athlon1800+ everything works perfectly. My other machine is a Pentium IV with hyperthreading, considered by Linux as SMP (x86 32). This is where problems occur 2) I have installed GHC-6.4.1 from Fedora Extras When I compile 'Omega' with it, Omega (which has a read-eval system) produces a 'mallocBytesRWX: failed to protect 0x' message I have compiled ghc-6.5... from the head. Compiled with GHC-6.4.1, I get the 'mallocBytesRWX...' message when I run 'ghci' 3) I have then patched 'RtsUtils.c' to suppress the 'barf("mallocBytesRWX...', and rerun- the compilation of ghc-6.5... 'Omega' compiled with the resulting ghc-6.5 works OK. ghci still produces the 'malloc...' error 4) When I compile ghc-6.5... with my patched ghc-6.5..., ghci does not produce the 'mallocBytesRWX' error (which is logical), but in some cases creates a 'segfault' So obviously the ghc-6.4.1 rpm is incorrect, as is the source ghc HEAD version. Probably an incorrect #ifdef here : #elif defined(openbsd_HOST_OS) || defined(linux_HOST_OS) || defined(darwin_HOST_OS) on a Pentium IV machine. And there is probably something else somewhere. Alain

2 1

unexpected ambiguity
by Niklas Sorensson 10 Apr '06

10 Apr '06

Hello, Trying to compile the attached modules gives the following error message: Main.hs:8:15: Ambiguous occurrence `lift' It could refer to either `Control.Monad.Trans.lift', ... or `Apa.lift', imported from Apa at ... Is this correct? I would have expected that an unqualified lift could only refer to the one exported from Apa in this case. /Niklas

2 2