- Glasgow-haskell-users

Problems with Network.Socket.getAddrInfo under MacOS 10.5, GHC 6.10.2?
by Neil Davies 05 May '09

05 May '09

Hi, It does not appear that you can access the 'addrFlags' returned by getAddrInfo, you get the exception: *** Exception: unpackBits: unhandled bits set: 8 Is this just a MacOS issue? Should I raise a ticket for it? Cheers Neil GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m Network.Socket Prelude Network.Socket> getAddrInfo Nothing (Just "localhost") Nothing Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.1 ... linking ... done. [AddrInfo {addrFlags = *** Exception: unpackBits: unhandled bits set: 8 Prelude Network.Socket>

3 5

ghc 6.10.3-prerelease failed build log for freebsd7.2
by brad clawsie 05 May '09

05 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi after some trying, i was unable to get the 6.10.3 prerelease to build on freebsd 7.2. i was trying to use an existing 6.10.2 as my build ghc. i saved the output of the entire build from ./configure to the point of failure. it is too long too attach here, you can see it at: http://www.b7j0c.org/ghc-6.10.3.log.txt it is about 4.4mb thanks brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkn+hQMACgkQxRg3RkRK91PGgACfWYJy9sIt6Nx1QxM+nkqXYMl3 pLIAoIDf6yw25VymUFPpdIG5L0B/gF2K =lwwy -----END PGP SIGNATURE-----

2 2

Linking and constants problems with OpenAL under Windows
by Jared 02 May '09

02 May '09

The OpenAL binding's wiki page directs questions to Haskell-Cafe, but the more serious of my problems seems to be with GHC. My platform is GHC 6.10.1 under Windows XP. This post boils down to two questions. First, why would GHCi and GHC look for different symbol names when linking, and second, has anybody had any success working with the OpenAL binding on Windows? If I write a program that uses Sound.OpenAL, I can load and run it in GHCi. If I try to compile the same program with ghc --make -lopenal32 audio.hs, I get a raft of errors like this: Linking audio.exe ... C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(BufferInternal.o):fake:(.text+0x5d): undefined reference to `alIsBuffer' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0x7d): undefined reference to `alcGetContextsDevice' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0xcd): undefined reference to `alcMakeContextCurrent' The names do not exist in openal32.lib. They should all be preceded by an underscore. GHC does the same thing if I convert the .lib file to a .a file. But why would GHCi do the right thing and GHC do the wrong thing? Am I missing a command line switch? I manually changed configure and configure.ac, per the patches (why weren't those applied to the library in Hackage?) to use ccall since OpenAL uses ccall instead of stdcall. Was there another change I should have made? The other problem is that several routines don't work properly because the constants don't get fixed up correctly during the build process. For example, the function marshalFormat in Sound.OpenAL.AL.Format should return 0x1100 when given Word8 as a parameter. It returns -1 instead; the code tells it to, but I assume some sed-like command was supposed to patch that with the right value. Has anybody had any luck getting this to work?

2 1

Re: type checking fails with a correct type
by Daniel Fischer 01 May '09

01 May '09

Am Donnerstag 30 April 2009 18:25:43 schrieb Jan Jakubuv: > Hello Daniel, > > On Thu, Apr 30, 2009 at 05:17:42PM +0200, Daniel Fischer wrote: > > In > > > > nonsense t = case nonsense t of > > Nothing -> Just empty > > > > , which type has the Nothing? > > It can have the type Maybe s1 for all s1 belonging to SUBST, that is the > > ambiguous type variable. > > thanks for the explanation. Maybe I'm starting to understand what is going > on. Now I understand it thus the call of `nonsense` inside the case > construct can potentially result in a different `SUBST`-type `s1` than the > top-level `nonsense`. That is why it has to be explicitly typed. > > But I am still not following why the type inference works fine without the > signature. Isn't it still ambiguous? Ah, that's a tricky one :) Without the type signature, the type of nonsense has to be inferred from scratch. We start with nonsense t = rhs so nonsense is a function, taking an argument of type argT, giving a result of type resT: nonsense :: argT -> resT Now we infer the type of the rhs, resT. case nonsense t of Nothing -> Just empty or, rewritten, let r = nonsense t in case r of Nothing -> Just empty now r is the result of applying nonsense to t, hence r :: resT. So Nothing has type resT. Since Nothing :: forall a. Maybe a, we can now deduce resT === Maybe b for some b we don't know anything about yet. In case r matches Nothing, the result is (Just empty), so b is the type of empty. empty has type (SUBST s => s), giving resT === SUBST s => Maybe s and nonsense :: SUBST s => argT -> Maybe s *Now* the free type variables are quantified, giving nonsense :: forall argT s. SUBST s => argT -> Maybe s Since in Haskell, type variables are implicitly universally quantified, the "forall argT s." part isn't necessary and not displayed. Here comes the snag: If you give the (implicitly universally quantified) type signature, you explicitly say that nonsense can return a value of type Maybe s, whatever s is, as long as it's a member of SUBST. But then the type-checker cannot assume that r and Just empty have the same type, thus it sees let r = nonsense t , from which it finds r :: forall s1. SUBST s1 => Maybe s1 on the other hand, it finds Just empty :: forall s2. SUBST s2 => Maybe s2, giving nonsense the ambiguous type nonsense :: forall t s1 s2. (SUBST s1, SUBST s2) => t -> Maybe s2 You can ask GHC by compiling the module without the type signature and with the flag -ddump-simpl , the relevant part of the core is: ================================================================== Nonsense.nonsense :: forall t_agD s_agJ. (Nonsense.SUBST s_agJ) => t_agD -> Data.Maybe.Maybe s_agJ [GlobalId] [Arity 2] Nonsense.nonsense = \ (@ t_agD) -- type of argument (@ s_agJ) -- type of result is (Maybe s_agJ) ($dSUBST_agL :: Nonsense.SUBST s_agJ) -- SUBST dictionary for s_agJ (eta_shh :: t_agD) -> letrec { nonsense1_agA :: t_agD -> Data.Maybe.Maybe s_agJ -- inner nonsense, the type is fixed as that at which the outer nonsense is called, -- there is *no* forall here! [Arity 1] nonsense1_agA = \ (t_afx :: t_agD) -> case nonsense1_agA t_afx of wild_Xk { Data.Maybe.Nothing -> Data.Maybe.Just @ s_agJ ($dSUBST_agL `cast` ((Nonsense.:Co:TSUBST) s_agJ :: (Nonsense.:TSUBST) s_agJ ~ s_agJ)); Data.Maybe.Just ipv_shd -> Control.Exception.Base.patError @ (Data.Maybe.Maybe s_agJ) "Nonsense.hs:(16,13)-(17,36)|case" }; } in nonsense1_agA eta_shh ================================================================== > > > {-# LANGUAGE ScopedTypeVariables #-} > > > > nonsense :: forall s. SUBST s => t -> Maybe s > > nonsense t = case nonsense t :: Maybe s of > > Nothing -> Just empty > > Great, ScopedTypeVariables is exactly what I was looking for. It solves all > my problems. Great :D > > Thank you, > Jan. Cheers, Daniel

2 1

Re: type checking fails with a correct type
by Jan Jakubuv 30 Apr '09

30 Apr '09

On Thu, Apr 30, 2009 at 10:20:44AM -0400, Brandon S. Allbery KF8NH wrote: > > http://www.haskell.org/pipermail/haskell-cafe/2008-April/041397.html > http://hackage.haskell.org/trac/ghc/ticket/1897 > Thanks for your answer and these links. Although the issue discussed there is more related to type families which were not used in my example, it was still helpful for me. At least now I know about the "show . read" problem ;-) Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

1 0

Re: type checking fails with a correct type
by Jan Jakubuv 30 Apr '09

30 Apr '09

Hello Daniel, On Thu, Apr 30, 2009 at 05:17:42PM +0200, Daniel Fischer wrote: > In > > nonsense t = case nonsense t of > Nothing -> Just empty > > , which type has the Nothing? > It can have the type Maybe s1 for all s1 belonging to SUBST, that is the ambiguous type > variable. > thanks for the explanation. Maybe I'm starting to understand what is going on. Now I understand it thus the call of `nonsense` inside the case construct can potentially result in a different `SUBST`-type `s1` than the top-level `nonsense`. That is why it has to be explicitly typed. But I am still not following why the type inference works fine without the signature. Isn't it still ambiguous? > > {-# LANGUAGE ScopedTypeVariables #-} > > nonsense :: forall s. SUBST s => t -> Maybe s > nonsense t = case nonsense t :: Maybe s of > Nothing -> Just empty > Great, ScopedTypeVariables is exactly what I was looking for. It solves all my problems. Thank you, Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

1 0

type checking fails with a correct type
by Jan Jakubuv 30 Apr '09

30 Apr '09

Hi, I have the following problem. Below is the smallest program I have found that shows the problem. That is why the program makes no sense (I have also meaningful but more complicated program). When I run this program in ghci: class SUBST s where empty :: s --nonsense :: SUBST s => t -> Maybe s nonsense t = case nonsense t of Nothing -> Just empty then everything is fine and I can see the type signature of `nonsense` inferred by ghci: *Main> :t nonsense nonsense :: (SUBST s) => t -> Maybe s But, when I put this signature into the code (that is, when the commented line above is uncommented) then type checking fails with the following error: Ambiguous type variable `s' in the constraint: `SUBST s' arising from a use of `nonsense' at problem-type.hs:6:18-27 Probable fix: add a type signature that fixes these type variable(s) Now, what is the problem here? Why does type checking fail with the signature that the type inference itself inferred? I am developing kind of generic interface and I don't want to fix the type `s`. I want `nonsense` to work possibly for any instance of SUBST and the concrete instance to be determined by the context where `nonsense` is used. In my original, meaningful but more complicated example I had the following error: Couldn't match expected type `STerm s' against inferred type `STerm s1' When generalising the type(s) for `refute' (this message does not provide any information where `s1` comes from) The original example shares with the above one the property that the type `s` is not mentioned in types of arguments, just in the type of a result (although, in the original example, some relation between types `t` and `s` is expressed in the type context via equality constrains on associated types (STerm from the error message) ). I tested this with ghc-6.6.1, ghc-6.10.1, ghc-6.10.2 obtaining the same result. BTW, I don't understand why but everything works fine with the following addition: nonsense' :: SUBST s => t -> Maybe s nonsense' t = case nonsense' t of Nothing -> Just empty x -> x I'll be grateful for any explanation of this issue. Sincerely, Jan. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

4 3

Threads and memory management
by Johannes Waldmann 30 Apr '09

30 Apr '09

Dear all, I was wondering what is the current status of the ghc RTS with respect to threading. Is it true that the allocator and deallocator (garbage collector) are still single-threaded? I made this example: import Control.Concurrent import Control.Concurrent.QSemN primes1 = sieve [ 2 .. ] primes2 = 2 : sieve [ 3, 5 .. ] sieve (x : ys) = x : sieve ( filter ( \ y -> 0 < y `mod` x ) ys ) main = do s <- newQSemN 0 forkIO $ do print $ sum $ take 10000 primes1 ; signalQSemN s 1 forkIO $ do print $ sum $ take 10000 primes2 ; signalQSemN s 1 waitQSemN s 2 Between the two computations, I see absolutely no data dependencies. So the naive expectation is that using two threads (in the RTS, on a multicore machine) gives half the execution time. I compiled with ghc-6.10.2 -o Par -O2 Par.hs -threaded and when I run with +RTS -N2 (instead of N1), I get my CPU load at 140 % (instead of 100) but the total run time (wall clock) stays nearly constant (i.e. CPU time goes up). For reference, I'm pretty sure a similar thing happens with the current mono implementation (they use Boehm GC and that does not know about C#/CIL threads ?), and this is preventing multi-core speedups in "straightforward" programs (that have no data dependencies, but lots of object creation, e.g. via (hidden) Enumerators and such.) Well, then, if the two Haskell threads are (nearly) completely independent like the above, it would be better to compile and run two separate executables and have them communicate via the OS (pipe or port). But that shouldn't be! (the OS being better than Haskell) Is there was a way of partitioning the memory (managed by the ghc RTS) in totally independent parts that each have their stand-alone memory management. Of course then all communication had to go via some Control.Concurrent.Chan, but that should be fine, if there is little of them. Well, just some thought. This idea can't be new? Tell me why it couldn't possibly work ... J.W.

5 7

Compiler modes / FFI / forcing CPP
by Philip Hölzenspies 30 Apr '09

30 Apr '09

Dear GHC-ers, From earlier questions, it seems no one wants to get down and dirty with linker tricks in ghc. I'm now looking over an alternative solution. I'm currently trying to use SDL. There's a wrapper on hackage, which works fine under Linux, but it takes some tinkering under Mac OS X, because OS X needs instantiated Cocoa stuff for the SDL entry point. Long story short, to use SDL with ghc on the OS X, a little wrapper c- file needs to be written, because the linker will find a 'main' function in libSDLmain.a which expects a function 'SDL_main' as an entry point into the user code. I have written a small c file that can be used to wrap around any haskell module (see below), based on the macro (cpp) definition of MODNAME. I can compile this c file with gcc, for, let's say a module Foo with entry point Foo.bar (so, if we could still have ghc make the entry point, we would say ghc -main-is Foo.bar): gcc -c -DMODNAME=Foo -D"ENTRYPOINT=bar();" -o Foo_entry.o entry.c However, this only works after I explicitly add ghc's "include" dir to my search path so that HsFFI.h can be found. Before I had this pre- processor trick, I could simply feed the c file to ghc, together with all my haskell files. Ghc then simply adds the correct includes and feeds the c file to the c compiler. Unfortunately, giving ghc the above -D options doesn't do much good. The problem seems to lie with the suffix recognition ghc does. I took this from [1]. With the -cpp switch, the c pre-processor is used, but only when the file has a .hs suffix. The c compiler is only run when the file has a .c suffix. Using -x .hs puts the file correctly through the c pre-processor, but then fails to compile it, because it's not haskell code. Using -x .c doesn't do pre-processing (even with -cpp). I tried to compile this wrapper using this command (assume now that we have Foo.hsMain as an entry point): ghc -cpp -pgmP cc -optP-E -DMODNAME=Foo -o Foo_entry.o entry.c (Notice that you can't just use cpp, because on OS X that's a shell script that doesn't provide CPPs full strength, so you want "cc -E".) This doesn't work: entry.c:27:2: error: #error MODNAME undefined! Trying to be more explicit as to where the -D should go: ghc -cpp -pgmP cc -optP-E -optP-DMODNAME=Foo -o Foo_entry.o entry.c does exactly the same. Now faking .hs: ghc -cpp -pgmP cc -optP-E -optP-DMODNAME=Foo -o Foo_entry.o -x hs entry.c which produces the error (coming from stdio.h inclusion): /usr/include/i386/_types.h:37:28: parse error on input `;' So, I guess my question is: Is it possible to let a c input file of ghc pass through *both* the c pre-processor *and* the c compiler? Kind regards, Philip [1] GHC User's Guide: Section 5.4: Modes of operation http://www.haskell.org/ghc/docs/latest/html/users_guide/modes.html entry.c: #ifdef MODNAME #ifndef ENTRYPOINT #define ENTRYPOINT hsMain(); #endif #include <stdio.h> #include "HsFFI.h" #define __HS_mangle(name) __stginit_ ## name #define __Xpand_HS_mangle(nm) __HS_mangle(nm) #define __hs_mangled_module __Xpand_HS_mangle( MODNAME ) #define __pack_quotes(x) #x #define __calc_include(x) __pack_quotes(x##_stub.h) #define __Xpand_calc_include(x) __calc_include(x) #include __Xpand_calc_include(MODNAME) extern void __hs_mangled_module ( void ); int SDL_main(int argc, char *argv[]) { hs_init(&argc, &argv); hs_add_root(__hs_mangled_module); ENTRYPOINT hs_exit(); return 0; } #else /* MODNAME */ #error MODNAME undefined! #endif /* MODNAME */

2 1

Multicore Haskell user experiences
by Scott Michel 29 Apr '09

29 Apr '09

[Sorry if this is the wrong place to hold this discussion... I'll move it if told to do so...] Simon P-J (et. al.) did recently publish a paper on making the Haskell runtime more multicore friendly, addressing the GC issue (among many things.) More broadly, though, there are two opportunities for multicore Haskell presentations: a) An IEEE conference in Pasedena, CA, July 19-21. The major theme is multicore in space (if you're familiar with OPERA/MAESTRO), but as a one of the conference-within-a-conference organizers, I'm interested in multicore programmability. Work on runtime environments, new language features, good-bad-and-ugly experiences, and "hard technical topics" are welcome. Looking for one or two presentations for this. b) Supercomputing '09 in Portland, OR next November. Focus here is primarily on user experience programming multicore with up-and-coming languages/environments. Any suggestions or presentation pitches are welcome. -scooter On Wed, Apr 29, 2009 at 3:01 AM, Johannes Waldmann <waldmann(a)imn.htwk-leipzig.de> wrote: >> PS: Anyone got a multicore Haskell experience they want to share at >> Supercomputing this year? The guys from Galois did a great job >> shocking the audience last year. > > well, this is my shocking experience: > http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/16809 > > where of course the conclusion is that parallelism > does not work "out of the box". No surprise? > While I completely would buy this statement for Java, C# etc > I hoped it was different for Haskell. > I don't want to rewrite my programs to make them less depend on GC. > Sure it could be done but then I could use Java from the start. > > J.W. > >

2 1