February 2005 - Glasgow-haskell-users

Download stats
by Simon Marlow 09 Feb '05

09 Feb '05

Hi folks, For the forthcoming 6.4 release, we'd like to get a rough idea of download statistics, at least from haskell.org. Both Simon & I are too busy/lazy (delete as applicable) to do this ourselves, and we don't know the best tools to use (grep|wc on the access_log is a bit too crude - we want to exclude things like partial downloads except when the download was completed later, etc.). Of course, if we can get or estimate download statistics for other sources of GHC too, that would be great. Any volunteers? Cheers, Simon

4 3

Unregistering a package
by Peter Simons 09 Feb '05

09 Feb '05

I have an interesting problem. There are two versions of the HsDNS package installed right now: $ ghc-pkg list | /usr/local/ghc-current/lib/ghc-6.5/package.conf: | rts-1.0, [...] (hsdns-2005-02-04), | hsdns-2005-02-08 Now how can I unregister them? I have tried everything I could think of, but no luck: $ ghc-pkg unregister hsdns | ghc-pkg: package hsdns matches multiple packages: | hsdns-2005-02-04, hsdns-2005-02-08 $ ghc-pkg unregister hsdns-2005-02-08 | ghc-pkg: cannot parse 'hsdns-2005-02-08' as a package identifier Can someone give me a pointer how to remedy this situation? Peter

1 0

ghc sensitive to struct layout
by Axel Simon 09 Feb '05

09 Feb '05

Good morning, gcc uses a different convention from the Microsoft environment when it comes to laying out fields in C structs, in particular bit fields. Can I pass the -optc--mms-bitfields to ghc when it compiles via C without negative effect? This flag is not implicit at the moment which I assume means that ghc itself is not compiled with --mms-bitfields on Windows. ghc surely includes struct declarations when it compiles the generated C files, so the question is whether all its structs are laid out the same regardless of which layout option one chooses. Thank, Axel.

1 0

GHC as a package
by Lennart Kolmodin 08 Feb '05

08 Feb '05

Hi! I'm working on an IDE for Haskell, written in Haskell. Currently, I'm looking for a way to parse .hs-files for a module browser and I recall that Simon Marlow was going to release GHC as a package "soon". We could also use that package to compile source code without invoking ghc as a separate process. What is the status of the package and where can I get it? I can't find it in the CVS or in any of the snapshots. /Lennart

1 0

RE: ghc-cvs-snapshot with wxHaskell
by Simon Marlow 08 Feb '05

08 Feb '05

On 07 February 2005 19:28, Patrick Scheibe wrote: > It seems that there are changes in the OpenGl library during the last > month. So I decided to load a really young cvs version of the ghc > (ghc-6.5.20050206-src.tar.bz2). The compilation works fine. > > My Problem is, that I also need the wxHaskell library. This > compilation fails with the message: > > <wxoutput> > ghc -c wxdirect/src/Map.hs -o out/wxdirect/Map.o -ohi > out/wxdirect/Map.hi -odir out/wxdirect/ -package parsec > -iout/wxdirect > sed: kann out/wxdirect/Map.d.in nicht lesen: Datei oder Verzeichnis > nicht gefunden > make: *** [out/wxdirect/Map.o] Fehler 2 > </wxoutput> > > The third line is german and means "sed: unable to read > out/wxdirect/Map.d.in: File not found". > This or an almost similar error appears when I use the cvs version of > wxhaskell. > > I'm also in contact with Daan Leijen, the main developer of wxHaskell. > He said: > > <daan> > Darn, it seems that ghc changed its options or something. My makefile > generates dependency files (".d" files) using ghc. Since "sed" can't > find the file, it is either not generated or it is put at the wrong > directory. Can you look around in your file system if there is a Map.d > or Map.d.in file somewhere around (maybe Map.hs.d.in ?) I guess it > is still in the source directory instead of the out/... directory. Could you tell us what command line was supposed to generate the Map.d.in or Map.d file? It may be a bug, there were a few changes in the driver recently. Cheers, Simon

2 1

ghc-cvs-snapshot with wxHaskell
by Patrick Scheibe 07 Feb '05

07 Feb '05

Hi, It seems that there are changes in the OpenGl library during the last month. So I decided to load a really young cvs version of the ghc (ghc-6.5.20050206-src.tar.bz2). The compilation works fine. My Problem is, that I also need the wxHaskell library. This compilation fails with the message: <wxoutput> ghc -c wxdirect/src/Map.hs -o out/wxdirect/Map.o -ohi out/wxdirect/Map.hi -odir out/wxdirect/ -package parsec -iout/wxdirect sed: kann out/wxdirect/Map.d.in nicht lesen: Datei oder Verzeichnis nicht gefunden make: *** [out/wxdirect/Map.o] Fehler 2 </wxoutput> The third line is german and means "sed: unable to read out/wxdirect/Map.d.in: File not found". This or an almost similar error appears when I use the cvs version of wxhaskell. I'm also in contact with Daan Leijen, the main developer of wxHaskell. He said: <daan> Darn, it seems that ghc changed its options or something. My makefile generates dependency files (".d" files) using ghc. Since "sed" can't find the file, it is either not generated or it is put at the wrong directory. Can you look around in your file system if there is a Map.d or Map.d.in file somewhere around (maybe Map.hs.d.in ?) I guess it is still in the source directory instead of the out/... directory. If it is not generated at all, things become more complicated .. </daan> Can anyone give a hint or knows the problem/change in the new ghc. Currently I'm working with ghc-6.2.1. Another solution is to get the OpenGl branch of the library path running with my old ghc. I tried it in my primitive and simple way and just copied the new OpenGL directory into my old source of ghc and recompiled it. The library fails to compile. Cheers Patrick

1 0

RE: Process library and signals
by Simon Marlow 07 Feb '05

07 Feb '05

On 02 February 2005 14:39, Glynn Clements wrote: > Simon Marlow wrote: >> I think this covers most of the useful situations. If you want to do >> the same thing in both parent and child, or handle in the parent and >> SIG_DFL in the child: use runProcess. If you want to ignore in the >> parent and SIG_DFL in the child: use System.Cmd.{system,rawSystem}. >> To handle in the parent and ignore in the child: unfortunately not >> directly supported. > > As it stands, you can have whatever behaviour you want in the parent: > set the desired handling before calling system/rawSystem/runProcess > then set it back afterwards. > > However, this will cease to be true for system/rawSystem if you change > them so that the child restores the handlers to their state upon > entry. I don't understand... is there a typo somewhere above? Perhaps you meant "child" in the first paragraph? system/rawSystem now behave almost exactly like system() in C. The only difference is that you can't ignore SIGINT/SIGQUIT in the child, but I can fix that if necessary. Cheers, Simon

2 1

RE: Unboxed Tuples
by Simon Peyton-Jones 07 Feb '05

07 Feb '05

| Thanks. Sorry if I'm being a bit dim, but could you tell me if ghc | will optimise out the boxed tuple construction in both these cases? It depends if the "..." is strict in 'p' or 'q'. If not, no it won't get optimised away, and rightly so. Exmape f x = let (p,q) = case h x of (# p,q #) -> (p,q) in (q,p) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Adrian Hey | Sent: 07 February 2005 13:03 | To: Simon Peyton-Jones; glasgow-haskell-users(a)haskell.org | Subject: Re: Unboxed Tuples | | On Monday 07 Feb 2005 9:28 am, Simon Peyton-Jones wrote: | > Good point. Yes you can rely on it; but the binding is lazy. So for | > this | > | > h :: Int -> (# String, String #) | > h = ... | > | > | > f x = let (# p,q #) = h x in ... | > | > you'll get | > | > f x = let (p,q) = case h x of (# p,q #) -> (p,q) | > in ... | > | > So the call to h only happens when either p or q is used. | > | > On the other hand, if any of the binders in a let-pattern has an | > unlifted type (e.g. Int#) then the whole pattern match becomes strict. | > So if p or q had an unlifted type, the match would be strict. | > | > I'll add a note to the usre manual. | | Thanks. Sorry if I'm being a bit dim, but could you tell me if ghc | will optimise out the boxed tuple construction in both these cases? | | I guess the answer must be yes in the second case because AFAIK | you can't build an ordinary tuple containing an Int#. (But maybe | I'm wrong.) | | Regards | -- | Adrian Hey | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Unboxed Tuples
by Simon Peyton-Jones 07 Feb '05

07 Feb '05

Good point. Yes you can rely on it; but the binding is lazy. So for this h :: Int -> (# String, String #) h = ... f x = let (# p,q #) = h x in ... you'll get f x = let (p,q) = case h x of (# p,q #) -> (p,q) in ... So the call to h only happens when either p or q is used. On the other hand, if any of the binders in a let-pattern has an unlifted type (e.g. Int#) then the whole pattern match becomes strict. So if p or q had an unlifted type, the match would be strict. I'll add a note to the usre manual. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Adrian Hey | Sent: 13 January 2005 11:55 | To: glasgow-haskell-users(a)haskell.org | Subject: Unboxed Tuples | | Hello, | | Does the user guide documentation for these reflect current ghc compiler? | | Para. 7.2.2 says they can only be deconstructed using case expressions | but by accident I've found they seem to work fine in let bindings too | (with ghc version 6.2.2). | | Not that I'm complaining (I always thought using case expressions was | just too painful :-). I just wanted to check that this is a feature | I can rely on in future (and if so suggest the user guide should be | ammended to reflect this). | | Regards | -- | Adrian Hey | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: STM check/MonadPlus
by Simon Peyton-Jones 07 Feb '05

07 Feb '05

Thanks for the typo. Yes, for Haskell guys 'guard' is fine; but the main audience for the paper is non-haskell folk, so we have to spell out the defn. S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Remi Turk | Sent: 06 February 2005 20:25 | To: glasgow-haskell-users(a)haskell.org | Subject: STM check/MonadPlus | | Hi, | | I have a few questions about the `check' function from | Control.Concurrent.STM. | | First, in the paper its definition contains a (type) error: | | check :: Bool -> STM a | check True = return () | check False = retry | | in fptools, however, it is defined as follows: | | check :: Bool -> STM a | check b = if b then return undefined else retry | | As we already have guard, and STM is an instance of MonadPlus, | I wonder why such a simple utility function as check is wanted | at all. | | guard :: (MonadPlus m) => Bool -> m () | guard True = return () | guard False = mzero | | Greetings, | Remi | | -- | Nobody can be exactly like me. Even I have trouble doing it. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1