- Glasgow-haskell-users

Re: Possible runtime overhead of wrapping the IO monad?
by Duncan Coutts 28 Mar '06

28 Mar '06

On Tue, 2006-03-28 at 01:37 +0100, Brian Hulley wrote: > Hi Duncan - > I just declared duma_vertex3f (in another module) by: > > foreign import ccall duma_vertex3f :: Float -> Float -> Float -> IO () > > I thought this means that the C function prototype must be: > > void duma_vertex3f(HsFloat, HsFloat, HsFloat); > > so I don't understand why GHC (or any other Haskell compiler) would ever > need to see a C header file to generate the correct code. What info could be > in the header that is not already in the Haskell type? Because ghc does compile via C and does use the C header files to get the C function prototype. Well it can compile via C and it's recommended when compiling FFI code since it allows the Haskell type you've declared to be checked against the C prototype. The warning you saw was coming from gcc as it compiled the C code emitted by ghc. So it's mostly as a sanity check but actually there is some information in the C prototype that is not reflected in the Haskell type. For example 'const'ness, which is why you might sometimes see warnings from gcc about casting away the const attribute. More seriously there is the single/double issue. In the absence of a prototype C will promote single to double. If the function really was declared as single then using double will probably cause a crash. There are probably other examples where not using a C prototype can lead to trouble. There are more probably details on this issue in the emails during the FFI standardisation process. Interestingly that particular issue is less of a problem when not compiling via C since the Haskell type does provide enough information for making a call using the standard system ABI. C's type sytem (such as it is) has slightly more information in it than just the system ABI needs (such as const). Duncan

3 5

RE: 6.4.1 Bug? getServiceEntry: does not exist (no such service entry)
by Simon Marlow 24 Mar '06

24 Mar '06

Binary snapshots allordy here: http://www.haskell.org/ghc/dist/stable/dist/ Cheers, Simon On 23 March 2006 16:54, S. Alexander Jacobson wrote: > Is there a 6.4.2 binary for winXP? I assuming doing a build from > source is non-trivial. > > -Alex- > > On Thu, 23 Mar 2006, Simon Marlow wrote: > >> S. Alexander Jacobson wrote: >> >>> I just upgraded to 6.4.1 from 6.4.0 and am now getting this error >>> when I run socket code via ghci, but not when I compile the code >>> using ghc. Any idea what this is or how to fix? >>> >>> getServiceEntry: does not exist (no such service entry) >> >> This was reported a while back, and I still have it on my queue to >> investigate: >> >> http://www.haskell.org//pipermail/haskell-cafe/2005-October/011777.html >> >> However, I just checked and it doesn't happen with a recent 6.4.2 >> snapshot, so I'm going to consider it fixed (probably another weird >> mingw version interaction, or something). >> >> Grab a 6.4.2 snapshot and you should be happy. >> >> Cheers, >> Simon >> > > ______________________________________________________________ > S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

4 4

Information for GHC users on Gentoo Linux
by Duncan Coutts 24 Mar '06

24 Mar '06

Information for GHC users on Gentoo Linux: GHC 6.4.1 has finally been marked stable on x86, amd64, sparc and ppc. (We also support ppc64, alpha and hppa.) http://packages.gentoo.org/search/?sstring=ghc We also have a collection of over 30 Haskell libraries and tools: http://packages.gentoo.org/packages/?category=dev-haskell http://packages.gentoo.org/search/?sstring=darcs Not all of these are marked stable yet. To emerge a package that is not yet marked stable, use this command: ACCEPT_KEYWORDS="~x86" emerge {pkgname} (substitute ~x86 for your arch as appropriate) Support and Bugs: * Bugs should be reported in the Gentoo bugzilla: http://bugs.gentoo.org/ * There is also a #gentoo-haskell irc channel on FreeNode. Filing bugs can also be used to ask for new packages or new versions of existing packages. We would like to encourage users to suggest any packages they feel are useful but are currently not included in portage (though note that we generally only package released versions of software where there are tarballs available and where there is an expectation that the software is maintained). For future reference this info is available from the haskell.org wiki: http://haskell.org/haskellwiki/Gentoo We have an ebuild for recent ghc-6.4.2 pre-release snapshots (and also for the latest darcs version of ghc-6.5). Anyone who would like to help us test this should contact us on irc for details. I'd like to thank the other members of Gentoo's Haskell 'herd' for their hard work in testing and fixing bugs which got us to this level of support. Duncan

1 0

6.4.1 Bug? getServiceEntry: does not exist (no such service entry)
by S. Alexander Jacobson 23 Mar '06

23 Mar '06

I just upgraded to 6.4.1 from 6.4.0 and am now getting this error when I run socket code via ghci, but not when I compile the code using ghc. Any idea what this is or how to fix? getServiceEntry: does not exist (no such service entry) FYI, I am running WinXP SP2. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

2 2

6.4.2 release plans
by Simon Marlow 23 Mar '06

23 Mar '06

Hi Folks, This is a heads up for the forthcoming 6.4.2 release. Our rough timescale is to go into release candidate testing in about a week, and have two weeks of release candidates before the final release. Here are the things we know about and plan to fix before the release: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… If you have anything else for 6.4.2, please let me know. Cheers, Simon

5 5

Re: Threaded runtime error
by Simon Marlow 22 Mar '06

22 Mar '06

Volker Stolz wrote: > * Volker Stolz <stolz(a)i2.informatik.rwth-aachen.de>: > >>timeout@menelaos [20:17:08]> ./timeout 10 /usr/bin/true >>FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in file /usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0) > > > A workaround seems to use another threading library here. Both > libthr and libc_r work at least for this small example. > > The error occurs on createOSThread(). I'm not sure where exactly > (ie., for the child or the parent, but I guess the child). > I'll keep on looking. If you can get me a backtrace, that would be most helpful. Cheers, Simon

1 0

Re: 6.4.2 release plans
by Simon Marlow 22 Mar '06

22 Mar '06

Duncan Coutts wrote: > Chris Parrott found that ghc-6.4.1 doesn't work with gcc 4.1 on amd64, > although it does work on x86. > > The error manifests itself as link errors due to undefined symbols: > > /var/tmp/portage/ghc-6.4.1-r2/work/ghc-6.4.1/ghc/rts/libHSrts.a(Linker.o):(.data+0x48): undefined reference to `StgReturn' > /var/tmp/portage/ghc-6.4.1-r2/work/ghc-6.4.1/ghc/rts/libHSrts.a(RtsStartup.o): In function `hs_add_root': > RtsStartup.c:(.text+0x1a8): undefined reference to `StgRun' Coincidentally, I just upgraded our x86_64 box to FC5, and the nightly build fell over with exactly these errors. It turns out that the HEAD already had fixes in some arch's for this, but it was fixed by making StgRunIsImplementedInAssembler() non-static. The attribute fix is better, so I've applied it consistently and merged to 6.4.2. Cheers, Simon

1 0

Show-ing GHC internal data structures
by David William Simmons-Duffin 21 Mar '06

21 Mar '06

I'm working with a friend on a project that involves hacking at the GHC internals. We'd like to be able to print some of the large data structures involved -- specifically a TcGblEnv. TcGblEnv is a record with a number of fields of different types, and it would be silly to go through the source adding "deriving Show" to the end of each type definition. It seems like Show instances for internal data structures would be useful for the GHC developers (for debugging purposes -- perhaps they were left out of the GHC distribution to keep the compiled code small?), and we were wondering if anyone had the relevant instance declarations lying around. Thanks, David

2 1

RE: RULES pragma with class constraint
by Simon Peyton-Jones 20 Mar '06

20 Mar '06

Definitely not at present, and I see no easy way to implement it. RULES are implemented by simple matching in Core. A call to nub will have an Eq dictionary, but Core knows nothing of instance declarations, and has no clue how to make an Ord dictionary. But an Ord dictionary is what you want on the RHS of the rule. The type checker, on the other hand, knows about dictionary construction, but nothing about RULES. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of John Meacham | Sent: 20 March 2006 11:49 | To: glasgow-haskell-users(a)haskell.org | Subject: RULES pragma with class constraint | | Is it possible to create a RULES that fires only if a type has a given | class constraint? something like: | | > snub :: Ord a => [a] -> [a] | > snub xs = f Set.empty xs where | > f _ [] = [] | > f (x:xs) set | > | x `Set.member` set = f xs | > | otherwise = x:f xs (Set.insert x set) | > | > | > {-# RULES "nub/snub" Ord a => forall a xs . nub (xs::[a]) = snub xs #-} | | Such a rule would probably only be able to fire on monotypes with known | instances since otherwise the dictionary won't necessarily be available. | but it seems like it might be a useful feature even with that | restriction. | | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RULES pragma with class constraint
by John Meacham 20 Mar '06

20 Mar '06

Is it possible to create a RULES that fires only if a type has a given class constraint? something like: > snub :: Ord a => [a] -> [a] > snub xs = f Set.empty xs where > f _ [] = [] > f (x:xs) set > | x `Set.member` set = f xs > | otherwise = x:f xs (Set.insert x set) > > > {-# RULES "nub/snub" Ord a => forall a xs . nub (xs::[a]) = snub xs #-} Such a rule would probably only be able to fire on monotypes with known instances since otherwise the dictionary won't necessarily be available. but it seems like it might be a useful feature even with that restriction. John -- John Meacham - ⑆repetae.net⑆john⑈

2 1