December 2005 - Glasgow-haskell-users

GCC in the Windows distribution of GHC
by cschmidt＠deds.nl 07 Dec '05

07 Dec '05

The Windows distribution of GHC includes GCC. Some header files (such as iostream, algorithm, and so forth), however, are missing (at least I was not able to find them). I could, of course, download the correct version of GCC (this must be version 3.2.3 for GHC 6.4), and put the header files where GCC can find them. I only wonder if this is the right thing to do. Were the header files omitted just to make the distribution smaller, or for some other reason? Cheers, Cyril

1 0

RE: New bug tracker: Trac
by Simon Marlow 07 Dec '05

07 Dec '05

On 06 December 2005 19:52, Gour wrote: > Simon Marlow (simonmar(a)microsoft.com) wrote: > >> The wiki is currently closed because I don't want to have to deal >> with spam. Use HaWiki for now. > > I got responses from people on #trac to disable entries from > non-registered user as a spam-prevention mechanism. Unfortunately there isn't a way for users to register themselves, we have to create them manually using htpasswd. I'm sure someone must have implemented an online user-registration system for Trac though? Cheers, Simon

2 1

RE: Happiness! Re: New bug tracker: Trac
by Simon Marlow 07 Dec '05

07 Dec '05

On 06 December 2005 17:45, Malcolm Wallace wrote: > Just one minor nit: the front page URL tells me a lot about Trac, > but nothing at all about ghc! > > Eventually, I worked out that I needed to click on "View tickets", > but it took a while to realise this. The top page of the wiki is now a bit more informative. This Trac thing is great! Cheers, Simon

1 0

Strictness annotations on type parameters
by Mario Blazevic 06 Dec '05

06 Dec '05

I spent several days last week trying to track a cause of a 100% slowdown after some trivial changes I made. The profiler didn't show any slowdown, presumably because it was dependent on optimizations, so I had to revert to tweak-run-measure cycle. It turned out the slowdown was caused by some unevaluated thunks that were kept around in long-lived IORefs. This is not the first time I was bitten by too laziness, either. What made things worse this time is that there is no way do declare the following: data Label = LabelRef {labelId:: !Unique, reference:: (IORef !LabelState), -- illegal origin:: Maybe !Label} -- illegal No container data type can be annotated as strict. That means I have to pepper my code with explicit evaluations to HNF before every writeIORef (reference label): newState `seq` writeIORef (reference label) newState What is the reason for this restriction on where strictness annotations can appear? Is it purely an implementation problem or is there a reason emanating from Haskell design? If former, how hard would it be to fix?

2 1

recommended build system
by Frederik Eaton 05 Dec '05

05 Dec '05

Hi all, I'm looking for a build system for my projects which will correctly handle all of ghc's dependencies. I.e. every time I ask it to rebuild an output file, it will only do the minimum amount of compilation necessary. This is important to me because "ghc --make" and cabal currently (AFAICT) will always relink an executable even when it is not necessary to do so; thus if I have a project with a bunch of libraries and executables, the cost of making a small modification and recompiling is very high, and it becomes hard to maintain focus on my projects after the initial design phase. I've just been playing around with GNU coreutils and was impressed with how well the build system works, and how fast the recompilation goes. Anyway, the system that darcs uses seems to work pretty well, should I copy that, or do people recommend other alternatives? Frederik

2 1

RE: Data.Typeable and default instances
by Simon Peyton-Jones 05 Dec '05

05 Dec '05

Jim You've found a strange corner case. Here's a cut-down example, which fails in exactly the same way. class Baz v x where foo :: x -> x -- Notice that v is not mentioned foo y = y instance Baz Int Int But it succeeds if you put the instance explicitly: instance Baz Int Int where foo y = y GHC does not actually macro-expand the instance decl. Instead, it defines a default method function, thus $dmfoo :: Baz v x => x -> x $dmfoo y = y Notice that this is an ambiguous type: you can't call $dmfoo without triggering an error. And when you write an instance decl, it calls the default method: instance Baz Int Int where foo = $dmfoo I'd never thought of that. You might think that we should just *infer* the type of the default method (here forall a. a->a), but in the presence of higher rank types etc we can't necessarily do that. So I'm not sure what to do. I've added it as an expected-failure test (tc199). I have not added a SourceForge bug because the original program seems so implausible. Meanwhile, the workaround is to define your own default method, thus: dmfoo :: x -> x dmfoo y = y instance Baz Int Int where foo = dmfoo Simom | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Jim Apple | Sent: 04 December 2005 17:24 | To: glasgow-haskell-users(a)haskell.org | Subject: Data.Typeable and default instances | | > {-# OPTIONS -fglasgow-exts #-} | > | > import Maybe | > import Data.Typeable | > | > data Nil = Nil deriving (Eq,Typeable,Show) | > | > class (Typeable t) => List a t where | > init :: (t -> b) -> (forall y . (List a y) => y -> b) | > init f z = fromJust $ do x <- cast z | > return $ f x | > | > instance List a Nil where | | Could not deduce (List a1 y) | from the context (List a Nil, Typeable Nil, List a y) | arising from use of `Main.$dminit' at Main.hs:21:0 | Probable fix: add (List a1 y) to the class or instance method | `Main.init' | In the definition of `init': init = Main.$dminit | In the definition for method `Main.init' | In the instance declaration for `List a Nil' | | but copying and pasting the code from init to the instance declaration | works fine. | | Jim | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: GHCI and archive libraries.
by Simon Peyton-Jones 05 Dec '05

05 Dec '05

I believe that it ought to be fairly straightforward to modify GHCi's linker (which is written in C) to understand .a files. Would someone like to try? Failing that, it'd be great if someone would feel able to write a few paras to summarise this thread, for us to add to the documentation. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Keean Schupke | Sent: 04 December 2005 14:28 | To: Sven Panne | Cc: Lennart Augustsson; glasgow-haskell-users(a)haskell.org | Subject: Re: GHCI and archive libraries. | | Thaks guys... I realise it is a simple matter of unpacking the object | files, however when using ghci for prototyping, it can be more | convenient to have all the '.o's packed into a '.a'. As it is a simple | matter to extract the .o files from the .a, I would have thought a | fairly small change to the ghci code would have enabled using archive | libraries. I think this change would aid usability. I don't know the | ghci code at all, so it would take me a long time to make this change, | as I would first have to understand the existing code. I was wondering | if anyone familier with the ghci code could add archive library support? | I suppose as a work around I could write a wrapper for ghci that | extracts the .o files from the .a to a temp directory, and then calls | ghci with the .o files on the command line. | | Regards, | Keean. | | Sven Panne wrote: | | >Am Samstag, 3. Dezember 2005 15:17 schrieb Lennart Augustsson: | > | > | >>And on many platforms (well, at least a few years ago) a "shared" | >>library doesn't have to be PIC. The dynamic loader can do relocation | >>when it loads the file. (Then it can't be shared.) | >> | >>But this was a few years ago on Solaris and BSDs, it could be | >>different now. | >> | >> | > | >After a quick look this seems to be the case on current x86 Linux systems, | >too: "Real" shared libraries consist of PIC to enhance sharing code at | >runtime, but nevertheless the dynamic loader seems to be able to load and | >relocate non-PIC, at the cost of less sharing, but often slightly better code | >quality. So the mentioned repacking of a static library into a partially | >linked object file might work for most common platforms. | > | >Cheers, | > S. | >_______________________________________________ | >Glasgow-haskell-users mailing list | >Glasgow-haskell-users(a)haskell.org | >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Data.Typeable and default instances
by Jim Apple 04 Dec '05

04 Dec '05

> {-# OPTIONS -fglasgow-exts #-} > > import Maybe > import Data.Typeable > > data Nil = Nil deriving (Eq,Typeable,Show) > > class (Typeable t) => List a t where > init :: (t -> b) -> (forall y . (List a y) => y -> b) > init f z = fromJust $ do x <- cast z > return $ f x > > instance List a Nil where Could not deduce (List a1 y) from the context (List a Nil, Typeable Nil, List a y) arising from use of `Main.$dminit' at Main.hs:21:0 Probable fix: add (List a1 y) to the class or instance method `Main.init' In the definition of `init': init = Main.$dminit In the definition for method `Main.init' In the instance declaration for `List a Nil' but copying and pasting the code from init to the instance declaration works fine. Jim

1 0

GHCI and archive libraries.
by Keean Schupke 04 Dec '05

04 Dec '05

GHCI does not load archive libraries. Is it possible (easy?) to get it to load (.a) archive libraries as well as .o and .so files? The problem is some optimized "cblas" libraries are not available as shared libraries due to the performace loss. Regards, Keean.

3 6

exhaustive pattern warning bug with irrefutable patterns
by John Meacham 04 Dec '05

04 Dec '05

the following gives a 'non-exhaustive pattern matching' error when it shouldn't. the ~-pattern always matches. It is not the function that is non-exhausitive, but the irrefutable binding, which are necessarily always non-exhausive so warning about it is the wrong thing to do. f :: [a] -> a f [x] = x f ~(_:xs) = f xs John -- John Meacham - ⑆repetae.net⑆john⑈

1 0