August 2011 - Glasgow-haskell-users

hp2ps Bug?
by Dominic Steinitz 17 Aug '11

17 Aug '11

If I use profiling on windows with relative path names e.g. the first line in the .hp file is something like: JOB "ScriptUsage.exe -t ..\FPF\TradeDesc\TradesTags.txt -f ..\out\FPOs - u ..\Data\LogStarted090511c +RTS -H256M -hc" then hp2ps produces nonsense. If I replace this line with: JOB "ScriptUsage.exe +RTS -H256M -hc" then it works. Is this a known bug or should I try to raise one? Thanks, Dominic.

1 0

Re: Type families difference between 7.0.4 and 7.2.1
by Brandon Allbery 17 Aug '11

17 Aug '11

(I'm adding glasgow-haskell-users to this; if I'm remembering incorrectly someone should correct me, if not then the namespace bit should be at least mentioned if not filed as a bug.) On Tue, Aug 16, 2011 at 00:44, Luite Stegeman <stegeman(a)gmail.com> wrote: > On Tue, Aug 16, 2011 at 6:33 AM, Brandon Allbery <allbery.b(a)gmail.com> > wrote: > > On Mon, Aug 15, 2011 at 08:12, Luite Stegeman <stegeman(a)gmail.com> > wrote: > >> -- C.hs > >> {-# LANGUAGE TypeFamilies #-} > >> module C where > >> > >> class C1 a where > >> data F a :: * > > > > I believe this is supposed to be syntactic sugar for a data family, so > 7.0.4 > > is wrong. (I also think it was a known deficiency.) > > In that case, why does module B export F, even though I imported C > qualified. Within B it can only be referred to as C.F > My specific recollection is that 7.0.x treated F as a data family without calling it one, which introduced some needless duplication in the code base and some oddities in usage, including possible core dumps for orphan instances. Again, 7.2.x is the correct reference; behavior of "class ... where data ..." in 7.0 is not consistent. And yes, not exporting the data-family-not-called-such was one of the inconsistencies in 7.0, 7.2's behavior being considered a bug fix for it. 7.0's behavior is actually a fairly serious bug, IIRC: instances of C1 not defined within C.hs would not correctly associate with the non-exported data family F and the code generated for them would crash at runtime. (Typeclasses are always global over an entire program; in effect, they are always exported, and you can't suppress it. Therefore a data family associated with a typeclass must also be exported always.) I suspect "Within B it can only be referred to as C.F" is a namespace bug, given that F must always be implicitly exported/imported to match the implicit export/import of C1. -- brandon s allbery allbery.b(a)gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

4 3

Type families difference between 7.0.4 and 7.2.1
by Luite Stegeman 16 Aug '11

16 Aug '11

hi, I've been trying to debug a problem with some code that causes name conflicts with GHC 7.2.1, but not with 7.0.4. The problem appears to be that in some cases, GHC 7.2.1 creates a top-level data family, that was not there with 7.0.4. Here's a small example: -- C.hs {-# LANGUAGE TypeFamilies #-} module C where class C1 a where data F a :: * -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import qualified C data B1 a = B1 a instance C.C1 (B1 a) where data C.F (B1 a) = B2 a data family D a -- ghci 7.0.4 > ghci B *B> :browse data B1 a = B1 a data instance B.R:FB1 (B1 a) = B2 a data family D a -- ghci 7.2.1 > ghci B *B> :browse data B1 a = B1 a data instance B.R:FB1 (B1 a) = B2 a data family D a data family F a I'm not sure what's going on, why there's a difference and whether this actually is the problem (and not just a difference in the :browse function). In the original code in which I ran into the problem, there's a similar top-level data family that wasn't there with GHC 7.0.4. The original issue is here: https://github.com/yesodweb/persistent/issues/17 , specifically there's a data family Field, that appears to cause conflicts with another Field type in Yesod. Unfortunately it's difficult to install the packages due to dependencies that have not yet been updated for 7.2.1, and the problem is further obscured by being buried inside template-haskell generated code. luite

2 1

RE: Superclass defaults
by Simon Peyton-Jones 15 Aug '11

15 Aug '11

| > If someone felt able to act as moderator for the discussion, willing | > to summarise conclusions, open questions, and so on, on the wiki | > page, that would be enormously helpful. | | I'm up for that role, if that's appropriate. I'll take you up on that, thank you! I've added some "SLPJ note" notes to http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances which could perhaps do with clarifying. Simon PS: to avoid spam, maybe now we have advertised this thread, we should restrict it to ghc-users? The *current* library question about mappend etc can stay on libraries.

1 0

HEAD does not build on OS X using 7.2.1 as bootstrap compiler
by Johan Tibell 14 Aug '11

14 Aug '11

Here's the error I get: compiler/nativeGen/PprBase.hs:26:8: Could not find module `Data.Array.Unsafe' Perhaps you meant Data.Array.Base (from array-0.3.0.3) Data.Array.Unboxed (from array-0.3.0.3) Use -v to see a list of the files searched for. This is from a clean tree.

3 2

INLINE pragma changes in 7.2.1
by Antoine Latter 13 Aug '11

13 Aug '11

Hi GHC, Did the behavior of the INLINE prgama change in version 7.2.1? I didn't see anything in the release notes. Previously (7.0.3) I could attach an inline pragma to a class member like so: class MyClass a with foo :: a -> Int {-# INLINE foo #-} Now I get the error message: "The INLINE pragma for default method `foo' lacks an accompanying binding" Is this change on purpose? Thanks, Antoine

2 2

foldP elemP
by Luca Ciciriello 10 Aug '11

10 Aug '11

I all. I've just installed GHC 7.2.1 In my code I import GHC.PArr but this new compiler doesn't find any more "foldP" and "elemP". Wich module I've to import in order to use "foldP" and "elemP". Thanks in advance for any answer. Luca

1 0

hsc2hs and #include
by Evan Laforge 09 Aug '11

09 Aug '11

So when I upgrade from 6.10 to 6.12 a LONG time ago, there was a bug where hsc2hs would emit INCLUDE pragmas and ghc didn't like that. So I hacked around it with an extra grep -v step in the Makefile. I always meant to go fix it for real in hsc2hs and finally I came back to that TODO item. I took a look at the hsc2hs source, and discovered it's surrounding the INCLUDE line with #elif __GLASGOW_HASKELL__ < 610 However, that macro is never defined for me, so it always emits the bogus INCLUDE line. I can't find anywhere that defines that macro, but there is a lot of "__GLASGOW_HASKELL && ...". So I modified utils/hsc2hs/C.hs from ... "#elif __GLASGOW_HASKELL__ < 610\n"++ " printf (\"{-# INCLUDE %s #-}\\n\", \""++ showCString s++"\");\n"++ "#endif\n" to "#elif __GLASGOW_HASKELL__ && __GLASGOW_HASKELL__ < 610\n"++ " printf (\"{-# INCLUDE %s #-}\\n\", \""++ showCString s++"\");\n"++ "#endif\n" And my problem is solved. Is this the correct solution? Where is that macro defined? I don't know how to mail patches with git, but anyway it's trivial so I don't think it's needed :)

4 11

Build failure of syb-with-class with ghc-7.2.1
by Bas van Dijk 09 Aug '11

09 Aug '11

Hello, the HEAD of syb-with-class fails with the following error when build with ghc-7.2.1 and template-haskell-2.6: http://code.google.com/p/syb-with-class/issues/detail?id=4 Is this a bug in TH? Regards, Bas

4 6

7.2.1-rc1 fails to build on kfreebsd-*, mips*, s390 and sparc
by Joachim Breitner 07 Aug '11

07 Aug '11

Dear GHC team, I have uploaded 7.2.1-rc1 to Debian experimental. It build fine on i386, amd64 and powerpc, but fails on the other architectures: https://buildd.debian.org/status/package.php?p=ghc&suite=experimental („last log“ gives you the full build log) The causes seem to be different. On kfreebsd, we get: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.2.0.20110728 for i386-unknown-kfreebsdgnu): Don't know if OSUnknown is elf This might be something that is easy to fix in compiler/utils/Platform.hs, but you will know better if one should add a new OS value, or reuse OSFreeBSD. On the other architectures there are complaints about static declarations following non-static declaration that I do not understand. I hope you do :-) With best regards, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 1