From trac at galois.com Wed Oct 1 01:34:21 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 01:31:09 2008 Subject: [GHC] #2151: GADTs in function Patterns In-Reply-To: <047.2f6478e8e827595da4825a54c1ec722c@localhost> References: <047.2f6478e8e827595da4825a54c1ec722c@localhost> Message-ID: <056.83dd0eccf26855602e6f115a476a4cf5@localhost> #2151: GADTs in function Patterns ------------------------------+--------------------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2151 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by chak): * testcase: => T2151 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 02:28:51 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 02:25:53 2008 Subject: [GHC] #2235: Bogus occurs check with type families In-Reply-To: <046.5974fa5687299769939135165fbad968@localhost> References: <046.5974fa5687299769939135165fbad968@localhost> Message-ID: <055.e9632eafc9bb4a287365822530ac8923@localhost> #2235: Bogus occurs check with type families ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by chak): * status: new => closed * resolution: => invalid Comment: We agreed that this {{{ tailList :: (b ~ Flip (Flip b)) => List a b -> List a (Flip b) }}} is not the right signature. The new solver doesn't produce the infinite-type error message, but the usual one where it complains about not being able to instantiate a rigid type. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 03:50:21 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 03:47:07 2008 Subject: [GHC] #2633: Broken windres in Windows installer In-Reply-To: <046.9b919ba8de4c365adabbc0dd415c4d16@localhost> References: <046.9b919ba8de4c365adabbc0dd415c4d16@localhost> Message-ID: <055.10e3973c0ba606ff55295f71c66bb4cd@localhost> #2633: Broken windres in Windows installer ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by NeilMitchell): * status: closed => reopened * severity: normal => major * resolution: duplicate => * summary: Template Haskell and windres => Broken windres in Windows installer * architecture: Unknown/Multiple => x86 * os: Unknown/Multiple => Windows Comment: A further email from the original reporter reveals that this version was not a compiled source version, but is the standard GHC 6.10 beta installer. Whoever compiled the GHC windows binary (Ian?) needs to fix their windres (upgrade or downgrade). This bug is very severe, and should probably block any Windows release of 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 03:50:57 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 03:47:43 2008 Subject: [GHC] #2235: Bogus occurs check with type families In-Reply-To: <046.5974fa5687299769939135165fbad968@localhost> References: <046.5974fa5687299769939135165fbad968@localhost> Message-ID: <055.abdb871ba094a848b76505f6bfda3b5f@localhost> #2235: Bogus occurs check with type families ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonpj): Just to fill in the details here. The type of `Cons` is {{{ Cons :: forall a b. forall c. (b ~ Flip c) => a -> List a c -> List a b }}} The task is this: {{{ b ~ Flip (Flip b), b ~ Flip c |- List a (Flip b) ~ List a c }}} And indeed that isn't provable. If we'd written the type of `Cons` the other way about, thus: {{{ Cons :: forall a b. a -> List a (Flip b) -> List a b }}} then we could prove it; but doubtless something else would go wrong. To do it right we'd have to give this type to `Cons` {{{ Cons :: forall a b c. (b ~ Flip c, c ~ Flip b) => a -> List a c -> List a b }}} Which we could. But it seems uncomfortably fragile. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 04:12:52 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 04:09:40 2008 Subject: [GHC] #1860: GMP dyn link dependencies in binary distributions In-Reply-To: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> References: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> Message-ID: <052.3e027aac6e5388833d10de49cb1d93a3@localhost> #1860: GMP dyn link dependencies in binary distributions ------------------------------+--------------------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by guest): Is this fixed in the current (6.8.3) binaries? plareplane@twenty:~/Desktop/ghc-6.8.3$ ./configure --prefix=$HOME/ghc checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu Which we'll further canonicalise into: x86_64-unknown-linux checking for path to top of build tree... utils/pwd/pwd: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory configure: error: cannot determine current directory plareplane@twenty:~/Desktop/ghc-6.8.3$ ldd utils/pwd/pwd linux-vdso.so.1 => (0x00007fffce3fe000) libutil.so.1 => /lib/libutil.so.1 (0x00007fc9c5ea3000) libdl.so.2 => /lib/libdl.so.2 (0x00007fc9c5c9f000) libm.so.6 => /lib/libm.so.6 (0x00007fc9c5a1e000) libgmp.so.3 => not found librt.so.1 => /lib/librt.so.1 (0x00007fc9c5815000) libc.so.6 => /lib/libc.so.6 (0x00007fc9c54b3000) /lib64/ld-linux-x86-64.so.2 (0x00007fc9c60a6000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc9c5297000) plareplane@twenty:~/Desktop/ghc-6.8.3$ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 04:15:11 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 04:12:01 2008 Subject: [GHC] #1860: GMP dyn link dependencies in binary distributions In-Reply-To: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> References: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> Message-ID: <052.3be2deef5618afd1dc4156e6dbb05367@localhost> #1860: GMP dyn link dependencies in binary distributions ------------------------------+--------------------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by guest): (Oops, double post for formatting.) Is this fixed in the current (6.8.3) binaries? {{{ plareplane@twenty:~/Desktop/ghc-6.8.3$ ./configure --prefix=$HOME/ghc checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu Which we'll further canonicalise into: x86_64-unknown-linux checking for path to top of build tree... utils/pwd/pwd: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory configure: error: cannot determine current directory plareplane@twenty:~/Desktop/ghc-6.8.3$ ldd utils/pwd/pwd linux-vdso.so.1 => (0x00007fffce3fe000) libutil.so.1 => /lib/libutil.so.1 (0x00007fc9c5ea3000) libdl.so.2 => /lib/libdl.so.2 (0x00007fc9c5c9f000) libm.so.6 => /lib/libm.so.6 (0x00007fc9c5a1e000) libgmp.so.3 => not found librt.so.1 => /lib/librt.so.1 (0x00007fc9c5815000) libc.so.6 => /lib/libc.so.6 (0x00007fc9c54b3000) /lib64/ld-linux-x86-64.so.2 (0x00007fc9c60a6000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc9c5297000) plareplane@twenty:~/Desktop/ghc-6.8.3$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 06:23:57 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 06:20:40 2008 Subject: [GHC] #2636: Error message for missing import substantially worse in 6.9/6.11 Message-ID: <051.f86bb43b82a519168d8fbe26645dafad@localhost> #2636: Error message for missing import substantially worse in 6.9/6.11 ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Creating a file Test.hs: {{{ import Foo main = print "hello" }}} where Foo does not exist, used to give a really nice error (with 6.8.3) but with 6.9 and 6.11 gives a horrible error message: {{{ $ runghc Test *** Exception: Could not find module `Foo': Use -v to see a list of the files searched for. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.11.20080929 }}} Compared to version 6.8.3: {{{ $ runghc Test.hs Test.hs:2:7: Could not find module `Foo': Use -v to see a list of the files searched for. }}} A much nicer error, importantly saying where the import was - in my case the import was in an imported module, so I didn't even know which file was causing the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 06:56:05 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 06:52:53 2008 Subject: [GHC] #1860: GMP dyn link dependencies in binary distributions In-Reply-To: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> References: <043.ec0a7f5109223df1eb9f14bc703bb201@localhost> Message-ID: <052.0fc65d3e0d2631cfbf3626dd662f01ec@localhost> #1860: GMP dyn link dependencies in binary distributions ------------------------------+--------------------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by igloo): On Linux you need to install libgmp. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 07:06:59 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 07:03:43 2008 Subject: [GHC] #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto-all' In-Reply-To: <045.6d20356736e6fa3c22e35dd97141b722@localhost> References: <045.6d20356736e6fa3c22e35dd97141b722@localhost> Message-ID: <054.cbd2c7c15be835e8685340177b940012@localhost> #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto- all' ----------------------+----------------------------------------------------- Reporter: pgavin | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed: {{{ Tue Sep 30 07:18:12 PDT 2008 Simon Marlow * Fix #2410: carefully generate unique names for CAF CCs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 07:07:50 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 07:04:35 2008 Subject: [GHC] #714: Inconsistency between handling functional dependencies in class and signature constraints In-Reply-To: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> References: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> Message-ID: <071.8ccbbb0d69524b025abbf10ae024240a@localhost> #714: Inconsistency between handling functional dependencies in class and signature constraints -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Comment (by claus): Replying to [comment:16 chak]: We're getting slightly off-topic for this ticket, but this is interesting. > Type families are neither strict nor lazy (or rather, I guess, you mean non-strict). In fact, given that the type language is supposed to be strongly normalising, the outcome of normalisation is independent of the evaluation order. > > There is absolutely no requirement that a family instance needs to be in scope in that example. Given the absence of instances for `TF`, `(TF a)` is simply a type that is only equal to itself and which is not inhabited, except for bottom. `(TF a)` is already fully normalised. I see. So you are interpreting TF as a term rewrite system, and a TF application that can't be reduced further is still a type (or whatever its kind says it is). Whereas I was interpreting TF as type-level functions, strict in the sense that they have to be evaluated until they give a (TF- application-free) type (or type constructor). So a TF application behaves as an existential type, but can be unwrapped by providing a matching TF instance, right? > So, I maintain, GHC is doing the right thing. I'll have to think about this interpretation of TF as mere rewrite systems a bit before I can agree or disagree, but this interpretation should probably be stressed in the TF documentation, to avoid similar misunderstandings. > But that name does not occur anywhere else. Hence, it will have no effect whatsoever on the typing of the rest of the program. All these examples were reduced to minimum, of course. Iirc, the idea was to use the variables introduced in the superclass context, and determined by FD, in the class declaration. Instance method types would then be determined by the combination of class declaration, instance head, and superclass instances, giving a net result similar to associated types. > Judging from your previous comment, I believe I know what you were trying to do. Given > {{{ > class TF a ~ b => CTF a > }}} > your intention was that whenever somebody declares an instance > {{{ > instance CTF t > }}} > the superclass rules would require that there is also an instance for `TF t`. Is that right? In particular, if `CTF` had a method `m :: a -> b`, then the instance would have a method type `m :: TF t ~ b => t -> b`. I'd like to repeat, though, that the ticket is about consistency and being able to bring into scope variables determined by FD or TF uniformly in all kinds of contexts (function, instance, class, data). Using this with TF instead of FD apparently isn't meant to work the way I thought it would (though it would still work for the non-reduced case, where the `b` actually occurs in the class declaration, right?), but at least it should be uniform for all contexts. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 07:20:39 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 07:17:21 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.65cf9bc9231b52ddc65b9abbf7e964c4@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Replying to [comment:6 claus]: > (a) just last week, I wanted to trace the import hierarchies of my 6.8.3 installation, for which I don't have sources Well, if we didn't have any orphan instances you wouldn't need to do that :-) In fact GHC does keep track of the import hierarchy in the .hi files, so you can do this using the GHC API (perhaps not everything you need is exposed via the official parts of the API currently though). > (b) even haddock needs package sources long enough to create its `*.haddock` files, and if any of the dependencies was installed without being haddocked, I need to be able to remedy that I don't buy this as an important use case. You should have Haddocked the package when you installed it, or it should be possible to download the package again, 'cabal haddock' and then install just the Haddock docs. > For Ghc Api clients like Ghc, I'd hope that extracting the source dirs from the package database, adding them to the import path and asking for `-fforce-recomp` would be sufficient, or that `-fforce-recomp` would look up the sources itself, but that might be optimistic?-) Sure you can put sources in your import path and then GHC will pick them up instead of the package modules, no -fforce-recomp necessary. But I think you're forgetting about the package metadata again - just having the sources won't be enough in many cases. > I'm not sure whether it would be sufficient, but is there any reason not to have a `src-dirs` field in installed packages descriptions? I'm not convinced it's useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 07:34:56 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 07:31:39 2008 Subject: [GHC] #2633: Broken windres in Windows installer In-Reply-To: <046.9b919ba8de4c365adabbc0dd415c4d16@localhost> References: <046.9b919ba8de4c365adabbc0dd415c4d16@localhost> Message-ID: <055.7c8efaa778075fd849a441d5a0e5adcb@localhost> #2633: Broken windres in Windows installer ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => duplicate Comment: It really is a duplicate of #2585 (and I agree it's a blocker). I thought I'd worked around the problem for the beta by re-installing an older version of MinGW, but apparently I still had the new windres, I'm not sure why. However, I've now installed the newer windres (2.18.50) which does indeed seem to work fine (tested with `-pgmwindres`), so future beta installers should be ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 07:38:27 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 07:35:14 2008 Subject: [GHC] #2585: New versions of windres fail with "windres: CreateProcess (null): No error" In-Reply-To: <044.25b69fd7b594ae443d31576c538df3be@localhost> References: <044.25b69fd7b594ae443d31576c538df3be@localhost> Message-ID: <053.7e9d6eecb6e272932541d7ad9f56986a@localhost> #2585: New versions of windres fail with "windres: CreateProcess (null): No error" ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): I've installed the newer version of windres (2.18.50) on the machine that builds the Windows installers, and checked that it does indeed fix the problem. So now we could either (a) try to find out why the 2.17.50 version doesn't work and find a workaround, or (b) document which versions of MinGW are incompatible with GHC, and make the configure script look for broken versions of windres. Obviously (a) would be a better result, but it's not essential. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 08:17:59 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 08:14:43 2008 Subject: [GHC] #2637: conc032(threaded2) fails with "thread blocked indefinitely" Message-ID: <047.a9cd05dfe37336a50d46953850a274fd@localhost> #2637: conc032(threaded2) fails with "thread blocked indefinitely" ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: conc032 Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ There's a race condition in `throwTo` where the target thread is running but just about to complete, so we end up with the source thread blocked on a `ThreadFinished` thread, and this is never noticed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 08:34:30 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 08:31:19 2008 Subject: [GHC] #2585: New versions of windres fail with "windres: CreateProcess (null): No error" In-Reply-To: <044.25b69fd7b594ae443d31576c538df3be@localhost> References: <044.25b69fd7b594ae443d31576c538df3be@localhost> Message-ID: <053.c1f527fce90bc4f89980463f3e41047d@localhost> #2585: New versions of windres fail with "windres: CreateProcess (null): No error" ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by NeilMitchell): I'd vote for (b) as its less work and as long as configure can give a good failure message, it doesn't matter. Where did you get the new version of windres from? I tried to find it, but failed completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 08:41:01 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 08:37:44 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.65f35c03bb7fb639234bf2175d67a8c2@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by claus): Replying to [comment:7 simonmar]: > In fact GHC does keep track of the import hierarchy in the .hi files, so you can do this using the GHC API (perhaps not everything you need is exposed via the official parts of the API currently though). Interesting. From `--show-iface`, I got the impression that cross-package imports weren't tracked? > > (b) even haddock needs package sources long enough to create its `*.haddock` files, and if any of the dependencies was installed without being haddocked, I need to be able to remedy that > > I don't buy this as an important use case. You should have Haddocked the package when you installed it, or it should be possible to download the package again, 'cabal haddock' and then install just the Haddock docs. There is no guarantee that all installed packages were haddocked. These days, one is locked into a specific haddock version, but I used to experiment with several. When developing packages, I change and reinstall them often, and I do sometimes keep separate package versions installed with separate compiler versions, so I'd have to reconstruct the exact package version and configuration options before trying to add haddocks. If one wanted to apply the haddock shipping with one version of ghc to sources hosted in another version of ghc, one would need access to the sources. > > For Ghc Api clients like Ghc, I'd hope that extracting the source dirs from the package database, adding them to the import path and asking for `-fforce-recomp` would be sufficient, or that `-fforce-recomp` would look up the sources itself, but that might be optimistic?-) > > Sure you can put sources in your import path and then GHC will pick them up instead of the package modules, no -fforce-recomp necessary. But I think you're forgetting about the package metadata again - just having the sources won't be enough in many cases. I'm not that forgetful;-) cabal calls `ghc --make` after setting things up, and at that stage, Ghc Api clients either have a chance, or they won't work with any form of the source. > > I'm not sure whether it would be sufficient, but is there any reason not to have a `src-dirs` field in installed packages descriptions? > > I'm not convinced it's useful. The point is to do the source download only once, then to cache the sources somewhere safe, and to make sure that tools can find the sources easily. I don't understand what is wrong with wanting to have the sources of open- source software available and easily accessible. But if you have alternative suggestions for helping source-based tools along, I'd be interested to hear them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 10:06:15 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 10:02:58 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.296cdd27ca5f5b1fe34f349df66d1e02@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Replying to [comment:8 claus]: > > Interesting. From `--show-iface`, I got the impression that cross- package imports weren't tracked? Try it with 6.10. > There is no guarantee that all installed packages were haddocked. These days, one is locked into a specific haddock version, but I used to experiment with several. When developing packages, I change and reinstall them often, and I do sometimes keep separate package versions installed with separate compiler versions, so I'd have to reconstruct the exact package version and configuration options before trying to add haddocks. If one wanted to apply the haddock shipping with one version of ghc to sources hosted in another version of ghc, one would need access to the sources. Right, but it's not just the sources - as you say, you need to construct the exact package version and config, so you'd need some kind of preprocessed sources and someone has to know exactly how to invoke Haddock (Cabal doesn't - it knows about Cabal packages, not source caches). > > Sure you can put sources in your import path and then GHC will pick them up instead of the package modules, no -fforce-recomp necessary. But I think you're forgetting about the package metadata again - just having the sources won't be enough in many cases. > > I'm not that forgetful;-) cabal calls `ghc --make` after setting things up, and at that stage, Ghc Api clients either have a chance, or they won't work with any form of the source. I'm afraid I just don't have a clue what you're talking about! What GHC API clients? A chance to do what? Cabal doesn't invoke any GHC API clients other than GHC. If you want to make some progress here, you'll have to provide a compelling use case, and describe it in very concrete terms. Without that, there's a danger that we'll provide something that nobody wants or can use. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 10:16:22 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 10:13:05 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.66787e445de01f79bbfca0514704e067@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by NeilMitchell): I think I understand the kind of things Claus wants to do (since I want to do similar things), but I think Simon is right. A package has little relation to the source code that built it - a package is related to the cabal tarball and configuration. One thing I (and Tim as well) want GHC to include with all packages is the External Core files. We are going to file a separate ticket aiming for 6.12, but it has a similar feel of maintaining additional information with a package, beyond that needed for compilation - so maybe these things need considering together. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 11:09:11 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 11:05:54 2008 Subject: [GHC] #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu In-Reply-To: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> References: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> Message-ID: <053.186b052aac0f97920a3a8c3bc1f02409@localhost> #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu ------------------------------+--------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: Keywords: OGI | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Done: {{{ Tue Sep 30 08:09:12 PDT 2008 Simon Marlow * Remove outdated link to OGI webpage }}} and the mtl library was fixed earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 11:23:53 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 11:20:36 2008 Subject: [GHC] #2637: conc032(threaded2) fails with "thread blocked indefinitely" In-Reply-To: <047.a9cd05dfe37336a50d46953850a274fd@localhost> References: <047.a9cd05dfe37336a50d46953850a274fd@localhost> Message-ID: <056.f031f7eb88521bd28a997a276a34bd74@localhost> #2637: conc032(threaded2) fails with "thread blocked indefinitely" ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: conc032 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Oct 1 06:55:49 PDT 2008 Simon Marlow * Fix #2637: conc032(threaded2) failure }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 12:10:08 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 12:06:51 2008 Subject: [GHC] #2634: tcIfaceGlobal (local): not found: In-Reply-To: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> References: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> Message-ID: <054.230a0c3fdb5cf274b11a7db753707d53@localhost> #2634: tcIfaceGlobal (local): not found: ----------------------+----------------------------------------------------- Reporter: Meddix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Very strange. Can anyone reproduce it? Can '''you''' reproduce it in a completely fresh tree? (I'm suspicious about old .hi files, for example.) If so, can you give instructions for what to download in what order, and what commands to issue to make it happen? thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 12:16:20 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 12:13:15 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.691842f27eb5bd8c6c508a15b871a90f@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): Another important use-case is if I have lots of libraries installed by Cabal, then at some later stage I realise that I want profiling versions of all of them. If the original sources were still lying around in a canonical location, this would probably be pretty easy. One thing I definitely don't want is for cabal-install to download and install ''different'' versions of those libraries, just because newer ones are available. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 12:20:56 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 12:17:49 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.b7a4e2c19c6f84d8f797df141e3b4f28@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by NeilMitchell): Another use case would be for people who want to upgrade to GHC HEAD once a day and would like to be able to install all the packages they had yesterday without much trouble. I currently have a script that does this, but its a lot more work than if GHC kept the tarballs around. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 1 16:53:22 2008 From: trac at galois.com (GHC) Date: Wed Oct 1 16:50:07 2008 Subject: [GHC] #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior Message-ID: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior -----------------------+---------------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: vax | Os: Windows -----------------------+---------------------------------------------------- See the attached test case, which should be self documenting. Compile with -threaded and call the program as either "testprog master read" or "testprog master noread" to view the two behaviors. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 00:57:22 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 00:54:08 2008 Subject: [GHC] #2448: Type equality constraint not propagated to superclass In-Reply-To: <044.69c727e94da0f0e8a02cdc7148428338@localhost> References: <044.69c727e94da0f0e8a02cdc7148428338@localhost> Message-ID: <053.d94f98a873933c219c42f590b7e40a61@localhost> #2448: Type equality constraint not propagated to superclass ------------------------------------------------------+--------------------- Reporter: conal | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: type families, type equality constraints | Difficulty: Unknown Testcase: T2448 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------------------+--------------------- Changes (by chak): * testcase: => T2448 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 01:04:47 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 01:01:32 2008 Subject: [GHC] #2102: Typeclass membership doesn't bring coercion superclass requirements into scope In-Reply-To: <044.023554459a3970ac357a8591131972fb@localhost> References: <044.023554459a3970ac357a8591131972fb@localhost> Message-ID: <053.22426bca55d20383b6f47e2a19ec05bd@localhost> #2102: Typeclass membership doesn't bring coercion superclass requirements into scope -------------------------------------+-------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: superclass equalities | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by chak): * keywords: => superclass equalities Comment: Sorry, but this one is not going to be fixed for 6.10.1. It requires an extension of the data structure between the type checker and desugarer to get the type-preserving translation right. This is too serious a change to attempt shortly before a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 01:20:54 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 01:17:34 2008 Subject: [GHC] #2639: Core lint failure with type families, data families, and typeclasses Message-ID: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> #2639: Core lint failure with type families, data families, and typeclasses ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ I haven't been able to shrink this case smaller and still fail core lint. {{{ {-# LANGUAGE TypeFamilies, EmptyDataDecls #-} module CoreLint where data Eps data family Work a v data instance Work Eps v = Eps v type family Dual a type instance Dual Eps = Eps class Connect s where connect :: (Dual s ~ c, Dual c ~ s) => Work s a -> Work c b -> (a,b) instance Connect Eps where connect (Eps a) (Eps b) = (a,b) }}} Output from ghc -dcore-lint is attached -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 01:23:26 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 01:20:06 2008 Subject: [GHC] #2639: Core lint failure with type families, data families, and typeclasses In-Reply-To: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> References: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> Message-ID: <053.6d8f460a985f2791ffb62de7ec073ed4@localhost> #2639: Core lint failure with type families, data families, and typeclasses ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by ryani): * version: 6.8.3 => 6.9 Comment: This is on GHC head as of 9/29. The problem doesn't seem to manifest in the program; everything still runs fine. It's possible the typechecker just isn't producing the correct evidence for the correct cast. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 01:50:40 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 01:47:25 2008 Subject: [GHC] #2291: Panic mixing RULES and Type Families In-Reply-To: <044.b4e939c7ecb85225e2cb80cd7a7bcd20@localhost> References: <044.b4e939c7ecb85225e2cb80cd7a7bcd20@localhost> Message-ID: <053.11754b616d6c848e4775a1344eaef51b@localhost> #2291: Panic mixing RULES and Type Families ------------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: type families, rewrite rules | Difficulty: Unknown Testcase: T2291 | Architecture: Unknown/Multiple Os: Linux | ------------------------------------------+--------------------------------- Changes (by chak): * testcase: attached => T2291 * status: new => closed * resolution: => fixed Comment: Works with the new solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 04:13:14 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 04:10:02 2008 Subject: [GHC] #2639: Core lint failure with type families, data families, and typeclasses In-Reply-To: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> References: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> Message-ID: <053.2df91e4107d576d8231d2e8c7f57e15f@localhost> #2639: Core lint failure with type families, data families, and typeclasses ------------------------------+--------------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => chak * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 04:25:26 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 04:22:04 2008 Subject: [GHC] #2640: Treat -X flags consistently in GHCi Message-ID: <046.b2636e2b36f002a0dd024f2921ea27a7@localhost> #2640: Treat -X flags consistently in GHCi ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Currently GHCi treats -X language extension flags as follows: the -X extension applies to both code typed to the GHCi prompt, and to modules loaded by GHCi. This happens whether the -X flag is given on the command line when invoking GHCi, or in a `:set` command. But there is one exception! The `-XExtendedDefaultRules` flag applies ''only'' to modules loaded by GHCi. For code typed at the GHCi prompt, the `-XExtendedDefaultRules` flag is always on, and cannot be switched off. This is (a) inconsistent and (b) awkward if you ''want'' to switch it off. Talking to Simon, the Right Thing seems to be to this: * GHCi should maintain two sets of flag settings: one for the GHCi prompt, and one for loaded modules * The two flat-sets are initialised identical, except that `-XExtendedDefaultRules` is set for GHCi. * Command-line flags are applied to both flag-sets. * The `:set` command affects both flag-sets * Add a new `:set-local` command to affect the GHCi prompt flag-set only. * (It's probably not worth a command that affects only the loaded modules.) It's not clear how urgent this is. Add yourself to cc list if you care, and add a comment. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 04:31:48 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 04:28:30 2008 Subject: [GHC] #2641: Make -XExtendedDeafultRules a bit less liberal Message-ID: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> #2641: Make -XExtendedDeafultRules a bit less liberal ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The `-XExtendedDefaultRules` flag is very liberal about type-class defaults. Perhaps too liberal: {{{ > *Main> quickCheck (\xs -> reverse xs == xs) > +++ OK, passed 100 tests. }}} Not good (reverse on lists is not the identity function). I expect a type error! Reason: reverse on list of () is indeed the identity function! [http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive- evaluation.html#extended-default-rules The rules] are currently these: * All of the classes Ci are single-parameter type classes. * At least one of the classes Ci is numeric, or is Show, Eq, or Ord. Maybe we should tighten up the second rule to say: * '''All''' of the classes Ci is numeric, or is Show, Eq, or Ord. Then the Quickcheck example would not bogusly succeed in typechecking, because there's an `Arbitrary` constraint involved. This ticket is to record the idea and canvas opinion. Record thoughts below. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 08:22:04 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 08:18:44 2008 Subject: [GHC] #2642: Improve SpecConstr for join points Message-ID: <046.b2eed70c8de5c8334b5f0d2bce85500e@localhost> #2642: Improve SpecConstr for join points -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------+---------------------------------- This is another `SpecConstr` improvement suggestion. See also #2598, #2255. Roman writes: Yes, this is turning into a major problem, in fact. This is the simplest example I could find: {{{ foo :: Int -> Int :*: (Int :*: Int) -> Int foo 0 p = p `seq` 0 foo i (m :*: (n1 :*: n2)) = case (case even (i-n1-n2) of True -> (i `div` 2, (n1-1) :*: (n2-1)) False -> (i-1, (n1+1) :*: (n2+1))) of (j, p) -> foo (if even i then i-m else i+m) ((m-1) :*: p) }}} The pattern here seems to be {{{ let j x = .... in ...(j (C a b)).... (j (C p q)) ... }}} So a C value is built every time j is called. Simon Marlow also saw something very similar in some STM code he was optimising recently. Here's a possible solution: * extend `SpecConstr` to work on *non-recursive* functions too. * look for the call pattern not in j's RHS (as we do for recursive fns) but in the body of the let A possible restriction is to do all this only for local, non-recursive fns that are themselves defined in the RHS of a recursive function. The motivation would be do it only when we're in a loop, and being in the body of a recursive function is a big clue. Do you think that would address the cases you've encountered? It would be a bit like making join-points eager to inline (specialisation is a bit like partial inlining) except that * we'd get sharing when there were two calls applied to the same constructor * it'd only happen if that argument was taken apart in the join point Roman comments: No, the last restriction is not good: we often have {{{ foo p = let j x' = ... foo (x',c) ... in ... j (C a) ... j (C b) ... }}} Here, the join point doesn't take apart the argument. In fact, this probably makes it a bit trickier: we want to specialise the join point and *then* specialise foo, getting {{{ foo p = let j x' = ... foo (x',c) ... {-# RULES j (C z) = j' z #-} j' z = ... foo (C z,c) ... in ... j' a ... j' b ... {-# RULES foo (C x,y) = foo' x y #-} foo' x y = ... }}} A problem is that for `SpecConstr` to specialise `foo`, `j` must be specialised and *simplified* first to expose the structure of the argument in the recursive call. Can this be done without running SpecConstr twice? Or is running `pecConstr/Simplify` repeatedly (until it produces no more specialisations) acceptable? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 09:17:31 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 09:14:10 2008 Subject: [GHC] #2631: Template Haskell weird error message In-Reply-To: <051.887408f1fe9f34c088e4f6e2dc848969@localhost> References: <051.887408f1fe9f34c088e4f6e2dc848969@localhost> Message-ID: <060.054599f468745f2d8753cc9182d0fd7f@localhost> #2631: Template Haskell weird error message ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Happily this is a different manifestation of #2597, and already fixed. The error message is now {{{ T2631.hs:4:12: Empty stmt list in do-block When splicing generated code into the program When splicing TH expression: CompE [] In the expression: $(return $ CompE []) In the definition of `main': main _ = $(return $ CompE []) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 09:35:12 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 09:32:04 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.0ff5bd914825ddaf4982f390e1924c1a@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Both of these sound like they would be easily solved by cabal-install caching the source tarballs for packages it downloads or builds, and having a facility for rebuilding a set of packages. I'm afraid I still don't see how adding anything to the package database will help here. Suppose there was a cache for package source tarballs somewhere on the system, and for each installed package you will either find a source tarball in the cache, or you can get it from Hackage. Now, you know which package versions are installed, if you know where the cache is you can find the source for any installed package. Isn't that be enough for all of the uses listed so far? And all of this can be managed by cabal- install, with no cooperation from GHC at all. What's more, it's already there - have a look in `~/.cabal/packages`! That's only for downloaded packages currently, but it would be possible to stash the sdist for any package you build in there. So can't all this be done by cabal-install? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 09:50:06 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 09:46:47 2008 Subject: [GHC] #2634: tcIfaceGlobal (local): not found: In-Reply-To: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> References: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> Message-ID: <054.e2559ba3bc936f17e76fbb779810f4f5@localhost> #2634: tcIfaceGlobal (local): not found: ----------------------+----------------------------------------------------- Reporter: Meddix | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by Meddix): * status: new => closed * resolution: => invalid Comment: You're right. Deleting the "dist" folder and recompiling, the problem disappears. I'm a novice in haskell and didn't think that could be an old files problem. I saw the "Please report this as a GHC bug" line and obeyed :) My fault. Meddix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 10:26:58 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 10:23:39 2008 Subject: [GHC] #2636: Error message for missing import substantially worse in 6.9/6.11 In-Reply-To: <051.f86bb43b82a519168d8fbe26645dafad@localhost> References: <051.f86bb43b82a519168d8fbe26645dafad@localhost> Message-ID: <060.7448b3cfd1d5bf95546b9b94e12c2bd7@localhost> #2636: Error message for missing import substantially worse in 6.9/6.11 ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Works fine with the inplace compiler: {{{ $ ~/builds-04/HEAD-1/ghc/stage2-inplace/ghc -c T2636.hs T2636.hs:3:0: Failed to load interface for `T2636_None': Use -v to see a list of the files searched for. }}} Could this be something to do with runghc? Or maybe fixed already? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 10:34:15 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 10:30:55 2008 Subject: [GHC] #2636: Error message for missing import substantially worse in 6.9/6.11 In-Reply-To: <051.f86bb43b82a519168d8fbe26645dafad@localhost> References: <051.f86bb43b82a519168d8fbe26645dafad@localhost> Message-ID: <060.8caa30a43a58fdc91818138b476bfe14@localhost> #2636: Error message for missing import substantially worse in 6.9/6.11 ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by NeilMitchell): Works fine with {{{ghc -c}}}, its just runghc/runhaskell that are worse. This is using a compiler from Monday, and I haven't seen any commits go past that would effect it. I'll try rebuilding anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 11:18:01 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 11:14:40 2008 Subject: [GHC] #2636: Error message for missing import substantially worse in 6.9/6.11 In-Reply-To: <051.f86bb43b82a519168d8fbe26645dafad@localhost> References: <051.f86bb43b82a519168d8fbe26645dafad@localhost> Message-ID: <060.36ef86d6ec64733380b4bd2e3017bf9a@localhost> #2636: Error message for missing import substantially worse in 6.9/6.11 ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by claus): This sounds a bit like untested fallout from the Ghc Api changes, as it seems to have been introduced between 20080918 and 20080907. Does this help? {{{ $ /cygdrive/c/ghc/ghc-6.9.20080918/bin/runghc Test.hs *** Exception: Could not find module `Foo': Use -v to see a list of the files searched for. $ /cygdrive/c/ghc/ghc-6.9.20080907/bin/runghc Test.hs Test.hs:1:7: Could not find module `Foo': Use -v to see a list of the files searched for. $ /cygdrive/c/ghc/ghc-6.11.20080925/bin/runghc Test.hs *** Exception: Could not find module `Foo': Use -v to see a list of the files searched for. }}} If this hunch is correct, it is probably worth watching out for other changes in error- and exception-handling. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 11:35:56 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 11:32:35 2008 Subject: [GHC] #2643: Optimized IntMap / IntSet construction from sorted input Message-ID: <048.5a067deefc3b5a1c5d97037f58a7321f@localhost> #2643: Optimized IntMap / IntSet construction from sorted input ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.8.3 | Severity: normal Keywords: containers | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Currently the "fromAscList" functions for building `IntMap`s and `IntSet`s are aliases for `fromList`. Building a trie in linear time from sorted input is not magic, and results in a considerable performance increase. See this post: http://www.haskell.org/pipermail/libraries/2008-May/009685.html My impression was that the list generally approved of the patch, but for some reason its never been applied so I'm creating a ticket for it here. Tests are included in the patch. Really it just modifies an existing test (which was `fromAscList xs == fromList xs`) so that it's no longer vacuous. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 11:42:16 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 11:38:56 2008 Subject: [GHC] #2644: type of IntMap.intersection[WithKey] is incorrect Message-ID: <048.cdf8c7c801b2eb701f7311923129020e@localhost> #2644: type of IntMap.intersection[WithKey] is incorrect ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.3 | Severity: normal Keywords: containers | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ `IntMap.intersectionWith` has declared type `(a -> b -> a) -> IntMap a -> IntMap b -> IntMap a` but the true type, correctly inferred by the compiler, is `(a -> b -> c) -> IntMap a -> IntMap b -> IntMap c`. This is also the type of the analogous function in the Data.Map library. This broader type signature is necessary for "zipping" maps, i.e. `intersectionWith (,)`. See list post : http://www.haskell.org/pipermail/libraries/2008-May/009677.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 11:56:05 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 11:52:46 2008 Subject: [GHC] #2636: Error message for missing import substantially worse in 6.9/6.11 In-Reply-To: <051.f86bb43b82a519168d8fbe26645dafad@localhost> References: <051.f86bb43b82a519168d8fbe26645dafad@localhost> Message-ID: <060.02e8ca1ff5a7c0ecc38e8da66b2ab1ae@localhost> #2636: Error message for missing import substantially worse in 6.9/6.11 ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * priority: normal => high * milestone: => 6.10.1 Comment: Yes, Claus is probably right, it looks like a regression due to the new GHC API stuff. Shouldn't be hard to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 12:03:03 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 11:59:42 2008 Subject: [GHC] #2645: fix type, performance of IntMap(Set).findMin(Max) Message-ID: <048.8a9f13834a53ec09c2896007b23bea4f@localhost> #2645: fix type, performance of IntMap(Set).findMin(Max) ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.8.3 | Severity: normal Keywords: containers | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The findMin / findMax functions for Data.IntMap currently return only the bound value, not the key, as is the case for Data.Map.findMin. These read-only queries are implemented using `maxView` which modifies the tree along the path from the root to the leaf, burning heap unnecessarily. I've provided a patch to implement these as simple recursive loops, as is done with Data.Map. Both of these issues impact the performance and usability of IntMaps when employed as purely functional arrays, maps from arbitrary ints to values. In this use case, I need to know what the range of used "addresses" is, so I can assign new ones for quickly appending items onto the front or back of the array, or offsetting the keys of one array before unioning it with another. See list post : http://www.haskell.org/pipermail/libraries/2008-May/009687.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 13:22:08 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 13:18:47 2008 Subject: [GHC] #2580: export Data.Map.toDescList In-Reply-To: <047.7323273a4c97569c35461c7770e620db@localhost> References: <047.7323273a4c97569c35461c7770e620db@localhost> Message-ID: <056.3cf07672caf1375274b6c87c2e4e78a5@localhost> #2580: export Data.Map.toDescList ------------------------------+--------------------------------------------- Reporter: elaforge | Owner: igloo Type: proposal | Status: reopened Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by sedillard): * status: closed => reopened * resolution: fixed => Comment: I've attached a patch which expands on Evan's changes and propagates them to `IntSet` and `IntMap`. Some (possibly controversial) changes of note : - Added `foldr` and `foldl` functions for the map types. This is redundant, but so is much of the interface. The argument to `foldlWithKey` has a strange type, `(a -> key -> value -> a)`, that does not place nice with `flip` and `const`. So I think its convenient to have `foldl` as well, and since we've got that why not throw `foldr` in too. - Specialized default implementations of `foldl` and `foldr` for `Foldable` class. This is perhaps better than exporting then from the map libraries. `Data.Sequence` does it this way, but the map libraries do not. If the API clutter is found to be unbearable then perhaps a major cleanup is in order, hiding all folds in the map/set modules and exporting them via `Foldable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 14:38:49 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 14:35:33 2008 Subject: [GHC] #2580: export Data.Map.toDescList In-Reply-To: <047.7323273a4c97569c35461c7770e620db@localhost> References: <047.7323273a4c97569c35461c7770e620db@localhost> Message-ID: <056.eb22a08c6a58f05d0c06bb1367001fe1@localhost> #2580: export Data.Map.toDescList ------------------------------+--------------------------------------------- Reporter: elaforge | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: This proposal has been applied. Please make a new ticket if you would like to make a new proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 15:19:27 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 15:16:10 2008 Subject: [GHC] #2646: Expand folding options for Sets and Maps Message-ID: <048.6604d7f856ddb37749ce7cc8864ce33b@localhost> #2646: Expand folding options for Sets and Maps ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.8.3 | Severity: normal Keywords: containers | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ xref #2580 , http://www.haskell.org/pipermail/libraries/2008-September/010653.html , http://www.haskell.org/pipermail/libraries/2008-October/010782.html I've attached a patch which expands on Evan's changes and propagates them to `IntSet` and `IntMap`. Some (possibly controversial) changes of note : * Added foldr and foldl functions for the map types. This is redundant, but so is much of the interface. The argument to foldlWithKey has a strange type, (a -> key -> value -> a), that does not play nicely with flip and const. So I think its convenient to have foldl as well, and since we've got that why not throw foldr in too. * Specialized default implementations of foldl and foldr for Foldable class. This is perhaps better than exporting then from the map libraries. Data.Sequence does it this way, but the map libraries do not. If the API clutter is found to be unbearable then perhaps a major cleanup is in order, hiding all folds in the map/set modules and exporting them via Foldable. Shall I also add strict versions? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 15:23:03 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 15:20:12 2008 Subject: [GHC] #2580: export Data.Map.toDescList In-Reply-To: <047.7323273a4c97569c35461c7770e620db@localhost> References: <047.7323273a4c97569c35461c7770e620db@localhost> Message-ID: <056.c7395083235c0e432c8e3f934b0168a6@localhost> #2580: export Data.Map.toDescList ------------------------------+--------------------------------------------- Reporter: elaforge | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by sedillard): See #2580, but really this is the same proposal, it just applies the changes to `Set`, `IntSet` and `IntMap` as well, keeping the APIs consistent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 15:24:09 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 15:21:26 2008 Subject: [GHC] #2580: export Data.Map.toDescList In-Reply-To: <047.7323273a4c97569c35461c7770e620db@localhost> References: <047.7323273a4c97569c35461c7770e620db@localhost> Message-ID: <056.23338c32ed4beef0b23af76b8486d897@localhost> #2580: export Data.Map.toDescList ------------------------------+--------------------------------------------- Reporter: elaforge | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by sedillard): Ugh I mean #2646. Sorry. I wish trac would let me edit comments without having to spam everybody. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 18:08:36 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 18:05:20 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.bed795cdd7508b6f9452e082a1c25b1c@localhost> #2337: Data.Array documentation utterly broken ------------------------------+--------------------------------------------- Reporter: japple | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by waern): We should make Haddock document re-exports from other packages properly. For this to work, GHC needs to provide `Binary` instances for `LHsDecl` and the types it contains. It would also be nice if it provided instances for `HsDoc` and `HaddockModInfo` which Haddock currently defines itself. We need the `Binary` instances so we can store the declarations and doc comments in the .haddock files. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 2 18:12:02 2008 From: trac at galois.com (GHC) Date: Thu Oct 2 18:08:41 2008 Subject: [GHC] #2647: Serious typo in IntMap.hs Message-ID: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> #2647: Serious typo in IntMap.hs ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.3 | Severity: critical Keywords: containers IntMap | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------+----------------------------------------- Someone has recently (since 6.8.3) taken a "style" pass over `IntMap.hs`. Apparently they didn't like reusing identifiers in different scopes, so they changed this function (at the very core of `IntMap`) from this {{{ highestBitMask :: Nat -> Nat highestBitMask x = case (x .|. shiftRL x 1) of x -> case (x .|. shiftRL x 2) of x -> case (x .|. shiftRL x 4) of x -> case (x .|. shiftRL x 8) of x -> case (x .|. shiftRL x 16) of x -> case (x .|. shiftRL x 32) of -- for 64 bit platforms x -> (x `xor` (shiftRL x 1)) }}} to this {{{ highestBitMask :: Nat -> Nat highestBitMask x0 = case (x0 .|. shiftRL x0 1) of x1 -> case (x1 .|. shiftRL x1 2) of x2 -> case (x2 .|. shiftRL x2 4) of x3 -> case (x3 .|. shiftRL x3 8) of x4 -> case (x3 .|. shiftRL x4 16) of x5 -> case (x4 .|. shiftRL x5 32) of -- for 64 bit platforms x6 -> (x6 `xor` (shiftRL x6 1)) }}} If you stare at it long enough, you might find the typo. Don't cheat and look at the patch. I'll give you a hint: quickcheck won't find it because the tests don't use big enough integers. Needless to say this completely breaks the library, and if it ain't broke... :) -- Ticket URL: GHC The Glasgow Haskell Compiler From malcolm.wallace at cs.york.ac.uk Fri Oct 3 04:26:14 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Oct 3 04:23:04 2008 Subject: [GHC] #2647: Serious typo in IntMap.hs In-Reply-To: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> References: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> Message-ID: > Someone has recently (since 6.8.3) taken a "style" pass over > `IntMap.hs`. > Apparently they didn't like reusing identifiers in different scopes, The reason someone made this change was to eliminate compiler warnings with -Wall, and as you rightly point out, the refactoring has introduced a new bug where there was no bug before (and there is no warning for this new bug). I think this illustrates the danger of the belief that warnings are themselves signs of danger. Sometimes a warning is simply an arbitrary style choice, and it is good practice to ignore it (or silence it) rather than change the code. Regards, Malcolm From trac at galois.com Fri Oct 3 04:42:33 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 04:39:09 2008 Subject: [GHC] #2648: Report out of date interface files robustly Message-ID: <046.fcbe859a05356d3f8331ef4b72030e02@localhost> #2648: Report out of date interface files robustly ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Suppose `X.hi` refers to `Y.f77`, but `Y.hi` is out of date and has no `f77`. Then you get a bad crash: {{{ (GHC version 6.8.3 for i386-unknown-mingw32): tcIfaceGlobal (local): not found: Please report this as a GHC bug }}} The solution lies within our grasp: * X.hi already contains a fingerprint for Y.hi * So, we should simply check Y.hi's fingerprint when we suck it in (Currently we do this fingerprint checking only for the module we are currently compiling, to see if the bits it depends on have changed.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 04:43:06 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 04:39:42 2008 Subject: [GHC] #2634: tcIfaceGlobal (local): not found: In-Reply-To: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> References: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> Message-ID: <054.0f9c7926c75b330e8860ab098ac4ffbd@localhost> #2634: tcIfaceGlobal (local): not found: ----------------------+----------------------------------------------------- Reporter: Meddix | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Comment (by simonpj): I don't agree that it's your fault. What's happening is this (I think). * GHC reads an interface file Foo.hi, whose contents refers to Bar.f88 * GHC looks for Bar.hi, and find it, but there is no Bar.f88 inside This is really a GHC bug -- it should behave in a more civilised fashion when it finds out-of-date hi files. Better still, Simon and I have just convinced ourselves that we know how to fix it. In fact I've created a ticket for it: #2648 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 05:30:15 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 05:26:58 2008 Subject: [GHC] #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior In-Reply-To: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> References: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> Message-ID: <052.2db85d08adc384e6879dd7d6fff6e33b@localhost> #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior -------------------------------+-------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: vax Os: Windows | -------------------------------+-------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: What happens in the "noread" case is that `runInteractiveCommand` spawns a shell to run "./rcTest noread", and then you terminate the shell by calling `terminateProcess`. Windows doesn't have the concept of process groups, so it doesn't kill the child process. I think this is behaving correctly. If you want to be able to kill the child reliably, I suggest using `runInteractiveProcess`, or the new `createProcess` (in 6.10) instead. I'm looking into the memory leak now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 05:43:19 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 05:40:07 2008 Subject: [GHC] #2634: tcIfaceGlobal (local): not found: In-Reply-To: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> References: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> Message-ID: <054.0e4f338f058862834df6d83e9ab3acf4@localhost> #2634: tcIfaceGlobal (local): not found: ----------------------+----------------------------------------------------- Reporter: Meddix | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Comment (by Meddix): Well, I'm glad I've been helpful, then. Meddix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 05:58:07 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 05:54:50 2008 Subject: [GHC] #2647: Serious typo in IntMap.hs In-Reply-To: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> References: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> Message-ID: <057.0f4bb0410142b228b20b9cef0dd3f50f@localhost> #2647: Serious typo in IntMap.hs ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: critical | Resolution: Keywords: containers IntMap | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------+----------------------------------------- Comment (by nominolo): I presume this was changed in order to avoid warnings (many of the core libraries are not {{{-Wall}}} clean yet). Good catch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 09:01:08 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 08:57:46 2008 Subject: [GHC] #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior In-Reply-To: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> References: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> Message-ID: <052.27ca83ae6da13233412efbaf8fc4fc44@localhost> #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior -------------------------------+-------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: vax Os: Windows | -------------------------------+-------------------------------------------- Comment (by claus): Replying to [comment:1 simonmar]: > What happens in the "noread" case is that `runInteractiveCommand` spawns a shell to run "./rcTest noread", and then you terminate the shell by calling `terminateProcess`. Windows doesn't have the concept of process groups, so it doesn't kill the child process. I was surprised by this last comment, as I had seen the option "end process tree" in Windows Task Manager (right click on a process). I haven't found anything on "process trees" directly, but there seems to the idea of a "job object" collecting groups of processes: http://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx That might not help in this particular case, if there's an intervening process that doesn't play the game, but it might still be useful in general when process groups are needed. It would be nice if everyone wouldn't use different names for similar concepts.. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 09:22:28 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 09:19:11 2008 Subject: [GHC] #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior In-Reply-To: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> References: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> Message-ID: <052.270bb78feee7557943fef39364c32b2b@localhost> #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior -------------------------------+-------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/process | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: vax Os: Windows | -------------------------------+-------------------------------------------- Changes (by simonmar): * milestone: => 6.10.1 Comment: Yes, we use job objects in the testsuite to ensure that when a test runs out of time we can kill it and all of its children. Ian did the necessary hackery, here: * [http://darcs.haskell.org/testsuite/timeout/WinCBindings.hsc] * [http://darcs.haskell.org/testsuite/timeout/timeout.hs] but as you say, I don't think this helps us with `terminateProcess`. We have no justification for creating a new job object for `runInteractiveCommand`, the parent process might well prefer it if we didn't (e.g. it would probably screw up the testsuite's use of job objects). BTW, I've verified the memory leak in the original bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 10:14:36 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 10:11:14 2008 Subject: [GHC] #2632: Template Haskell confused by operator fixity In-Reply-To: <046.8dd0bbd9b32e6728a7a0c1c7930594d5@localhost> References: <046.8dd0bbd9b32e6728a7a0c1c7930594d5@localhost> Message-ID: <055.97b7fe753a86ac59382baa7e96ba6d60@localhost> #2632: Template Haskell confused by operator fixity ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T2632 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * testcase: => th/T2632 * owner: simonpj => igloo * type: bug => merge Comment: Excellent point. This turned out to be a very dark corner, so good to find. Thanks. {{{ Fri Oct 3 15:04:23 BST 2008 simonpj@microsoft.com * Expunge ThFake, cure Trac #2632 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 10:23:20 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 10:19:55 2008 Subject: [GHC] #2649: 6.10 regression: panic in tyFamInsts on invalid code Message-ID: <047.782af07c34bab674c1b20c9e69317506@localhost> #2649: 6.10 regression: panic in tyFamInsts on invalid code -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- {{{ {-# LANGUAGE ScopedTypeVariables, Rank2Types #-} module Asdf where g :: Num a => a -> (forall a. a -> Int) -> Int g = flip id f = g 0 $ \(_ :: forall a. Num a => a) -> 0 }}} {{{ >ghc -c asdf.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081002 for i386-unknown-mingw32): types\Type.lhs:(881,0)-(889,46): Non-exhaustive patterns in function tyFamInsts }}} With 6.8.2 I get instead the following, which I think is correct: {{{ ] ghc -XPatternSignatures -c asdf.hs asdf.hs:7:12: Couldn't match expected type `a' against inferred type `forall a1. (Num a1) => a1' `a' is a rigid type variable bound by the polymorphic type `forall a. a -> Int' at asdf.hs:7:4 In the pattern: _ :: forall a. (Num a) => a In the second argument of `($)', namely `\ (_ :: forall a. (Num a) => a) -> 0' In the expression: g 0 $ \ (_ :: forall a. (Num a) => a) -> 0 }}} On the other hand, replacing `f` with: {{{ f = g 0 $ ((\_ -> 0) :: forall a. Num a => a -> Int) }}} Works fine. I don't know why the original code is invalid but it certainly shouldn't cause a panic. 6.10 wasn't available in the "Version" listing so I filed this for 6.9. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 13:10:46 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 13:07:23 2008 Subject: [GHC] #2647: Serious typo in IntMap.hs In-Reply-To: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> References: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> Message-ID: <057.e63a21e2fa14f3b8dc66c7dff213c10a@localhost> #2647: Serious typo in IntMap.hs ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: critical | Resolution: Keywords: containers IntMap | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------+----------------------------------------- Comment (by sedillard): Oh, my mistake. I'm not familiar with the types of things -Wall warns abouts. TBH I don't use it. Now I'll have to get in the habit. I hope I didn't come off as smug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 13:21:24 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 13:18:09 2008 Subject: [GHC] #2647: Serious typo in IntMap.hs In-Reply-To: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> References: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> Message-ID: <057.dbd243b1c4f681abb045371aea64631e@localhost> #2647: Serious typo in IntMap.hs ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: critical | Resolution: Keywords: containers IntMap | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------+----------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): No need to apologise. The fact that someone introduced a new bug, by changing the code to remove a -Wall warning, is a salutary lesson in the danger of trusting a mechanical warning system to tell you about real problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 14:18:13 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 14:14:48 2008 Subject: [GHC] #2650: System.Process: processes may unwantedly inherit Handles on Windows when multithreading Message-ID: <047.1449ef20e3242d7624bded23f58b28e1@localhost> #2650: System.Process: processes may unwantedly inherit Handles on Windows when multithreading -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.9 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- `runInteractiveProcess` (the one in `runProcess.c`, not the Haskell one) calls `CreateProcess` with `bInheritHandles` set to `TRUE`, but the whole thing is not wrapped in a critical section. Microsoft has [http://support.microsoft.com/kb/315939 a decent explanation of why this is a problem] and I found that it's [http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6428742 a two-year old unfixed bug in the Java runtime] as well. In case it's not obvious, the reason why we don't want Handles to be inherited is that then a child process may hang on to it well after it should have been closed. The end result is that trying to do anything to it results in a sharing violation. The case in which I originally ran into this was `System.Directory.copyFile` intermittently reporting a "permission denied" error for a temp file it was using. I think it was trying to delete it, but failing because a child process somewhere was hanging on to the Handle. Attached is code demonstrating the problem. It forks a thread which repeatedly tries to open and close the file `foo.tmp`. The main thread then spawns processes as fast as it can until the other one fails to open the file. This, I think, cannot happen on non-Windows platforms since two processes can have the same file open without trouble. '''Do not run except on Windows, you risk flooding your system with `ping` processes.''' It may be sensible to make this controllable with the `close_fds` parameter to `createProcess`, which is currently just ignored on Windows. I can't see why anybody could ever want this behaviour, though. I've tested only process-1.0.1 with it, and the `openFile` fails reliably after spawning up to about 4 processes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 14:53:56 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 14:50:42 2008 Subject: [GHC] #2647: Serious typo in IntMap.hs In-Reply-To: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> References: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> Message-ID: <057.03b4c2f31a8dd95b561712ce1f11e3e6@localhost> #2647: Serious typo in IntMap.hs ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: critical | Resolution: Keywords: containers IntMap | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------+----------------------------------------- Comment (by dons): How about adding a QuickCheck property that can distinguish the error, so it can't happen again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 15:53:38 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 15:50:26 2008 Subject: [GHC] #2647: Serious typo in IntMap.hs In-Reply-To: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> References: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> Message-ID: <057.c8c7efefd27c752f638ae5f67cab0c76@localhost> #2647: Serious typo in IntMap.hs ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: critical | Resolution: Keywords: containers IntMap | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------+----------------------------------------- Comment (by sedillard): The properties are fine. (Well, each one on its own is fine. Together they don't cover the entire library, but that's another issue.) The problem was that the default Arbitrary instance for Int generates small numbers, so building on top of that we get trees filled with small numbers. I've changed the Arbitrary instance for IntMap / IntSet to flip random bits before building the tree. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 16:39:14 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 16:35:48 2008 Subject: [GHC] #2651: BlockedIndefinitely not thrown when it should be Message-ID: <047.e9da191bb9568ef4d909376b59b9027c@localhost> #2651: BlockedIndefinitely not thrown when it should be -------------------------+-------------------------------------------------- Reporter: govereau | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- The following program demonstrates the bug. When run with no arguments, the "die" thread gets a BlockedIndefinitely exception, when run with command line arguments it does not. {{{ module Main where import Control.Monad import Control.Concurrent import Control.Concurrent.STM import System.Environment main :: IO () main = do { flags <- getArgs ; if (length flags > 0) then forkIO die >> -- die does not die threadDelay 10000000 else die -- die dies } -- expect BlockedIndefinitely exception to be thrown die :: IO () die = newTVarIO "die" >>= f >>= print where f tv = atomically $ do { x <- readTVar tv ; if x == "die" then retry else return x } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 17:17:58 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 17:14:33 2008 Subject: [GHC] #2506: infix assert panics ghc In-Reply-To: <044.3043ed924f65ac215b3b93b6e6566455@localhost> References: <044.3043ed924f65ac215b3b93b6e6566455@localhost> Message-ID: <053.dc66f7937946f1e913040b16053fc494@localhost> #2506: infix assert panics ghc -----------------------------------------+---------------------------------- Reporter: galen | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_compile/T2506 | Architecture: x86 Os: Linux | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We won't be releasing 6.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 17:18:02 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 17:14:48 2008 Subject: [GHC] #2478: Assertion failure in type checker In-Reply-To: <046.2c7a75307faaed6cba46d8a9903f5b6b@localhost> References: <046.2c7a75307faaed6cba46d8a9903f5b6b@localhost> Message-ID: <055.1f8f87a2147d6c8092827448797ead97@localhost> #2478: Assertion failure in type checker --------------------------------------------+------------------------------- Reporter: simonpj | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2478 | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We won't be releasing 6.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 17:18:00 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 17:14:49 2008 Subject: [GHC] #2486: Code specialization regression in 6.8.3 In-Reply-To: <044.2aa9bce2a7a3fda66c24d4bd23fa1ccd@localhost> References: <044.2aa9bce2a7a3fda66c24d4bd23fa1ccd@localhost> Message-ID: <053.02922a4882c6c873d3f42c222dd56372@localhost> #2486: Code specialization regression in 6.8.3 ----------------------------------------+----------------------------------- Reporter: dolio | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simplCore/should_run/T2486 | Architecture: x86_64 (amd64) Os: Linux | ----------------------------------------+----------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We won't be releasing 6.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 17:18:05 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 17:14:50 2008 Subject: [GHC] #2433: standalone deriving Typeable shouldn't need data constructors in scope? In-Reply-To: <044.c3db89885eba9cc62656744d598e567c@localhost> References: <044.c3db89885eba9cc62656744d598e567c@localhost> Message-ID: <053.022d41271ca2afe5c36bd98e63c2d170@localhost> #2433: standalone deriving Typeable shouldn't need data constructors in scope? --------------------------------------------+------------------------------- Reporter: claus | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2433 | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We won't be releasing 6.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 17:18:10 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 17:14:50 2008 Subject: [GHC] #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable In-Reply-To: <053.8442170ef9b4829325987986f707598b@localhost> References: <053.8442170ef9b4829325987986f707598b@localhost> Message-ID: <062.66dc120f4d78bdaba5bdcca6c09f77d3@localhost> #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T2386 | Architecture: x86_64 (amd64) Os: MacOS X | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We won't be releasing 6.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 17:18:16 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 17:15:01 2008 Subject: [GHC] #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 In-Reply-To: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> References: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> Message-ID: <062.faff1ead06aa9cae1c188877690cf459@localhost> #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: gadt/records | Architecture: Unknown/Multiple Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We won't be releasing 6.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 17:18:14 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 17:15:02 2008 Subject: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data In-Reply-To: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> References: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> Message-ID: <053.8b581387110a546987b718a9b7e657b1@localhost> #2378: panic: lookupVers1, when standalone deriving Typeable and Data -------------------------------------------+-------------------------------- Reporter: guest | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T2378 | Architecture: x86 Os: MacOS X | -------------------------------------------+-------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We won't be releasing 6.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 17:18:20 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 17:15:03 2008 Subject: [GHC] #2358: Template Haskell's TupleT considers unary tuples as a valid types. In-Reply-To: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> References: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> Message-ID: <052.76b480cf76fa233cc7c7971d892d79fa@localhost> #2358: Template Haskell's TupleT considers unary tuples as a valid types. ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: TH_1tuple | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We won't be releasing 6.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 17:18:23 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 17:15:04 2008 Subject: [GHC] #2414: GHCi / GHC segfault : type checker problem In-Reply-To: <043.07db70092bd8811bd5934348939d4781@localhost> References: <043.07db70092bd8811bd5934348939d4781@localhost> Message-ID: <052.c2e43c08382a2e3fac7cd9225490642f@localhost> #2414: GHCi / GHC segfault : type checker problem -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: merge | Status: closed Priority: high | Milestone: 6.8 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2414 | Architecture: Unknown/Multiple Os: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We won't be releasing 6.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 18:56:06 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 18:52:42 2008 Subject: [GHC] #2637: conc032(threaded2) fails with "thread blocked indefinitely" In-Reply-To: <047.a9cd05dfe37336a50d46953850a274fd@localhost> References: <047.a9cd05dfe37336a50d46953850a274fd@localhost> Message-ID: <056.13586d5f06de17fb612914d96cf1602e@localhost> #2637: conc032(threaded2) fails with "thread blocked indefinitely" ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: conc032 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 18:56:36 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 18:53:11 2008 Subject: [GHC] #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu In-Reply-To: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> References: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> Message-ID: <053.69485586fa61f8558bfa63954e20f983@localhost> #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu ------------------------------+--------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: fixed Keywords: OGI | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 18:57:15 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 18:53:50 2008 Subject: [GHC] #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto-all' In-Reply-To: <045.6d20356736e6fa3c22e35dd97141b722@localhost> References: <045.6d20356736e6fa3c22e35dd97141b722@localhost> Message-ID: <054.3d620ef7a2ba3e2dff2b22b19ed86d0a@localhost> #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto- all' ----------------------+----------------------------------------------------- Reporter: pgavin | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 3 18:57:33 2008 From: trac at galois.com (GHC) Date: Fri Oct 3 18:54:09 2008 Subject: [GHC] #2295: Combined -odir/-hidir flag In-Reply-To: <051.3ec75d5010176a8f7458111511793c49@localhost> References: <051.3ec75d5010176a8f7458111511793c49@localhost> Message-ID: <060.fbc4c323d61ddea4439d30ea4f97d230@localhost> #2295: Combined -odir/-hidir flag ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 06:05:34 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 06:02:07 2008 Subject: [GHC] #2652: fancier prompts for ghci Message-ID: <043.a8f4d98c7c46b6cf0ed186a84ca3ef31@localhost> #2652: fancier prompts for ghci ---------------------------------+------------------------------------------ Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ It'd be nice to put newlines in a GHCi prompt using standard escape sequences. It is really unnecessary to support anything more than `%s` as a formatting directive. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:31:42 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:28:14 2008 Subject: [GHC] #2632: Template Haskell confused by operator fixity In-Reply-To: <046.8dd0bbd9b32e6728a7a0c1c7930594d5@localhost> References: <046.8dd0bbd9b32e6728a7a0c1c7930594d5@localhost> Message-ID: <055.4c90d34b32e23de2f35740cf9d728d5f@localhost> #2632: Template Haskell confused by operator fixity ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T2632 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:33:24 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:30:06 2008 Subject: [GHC] #1136: High memory use when compiling many let bindings. In-Reply-To: <044.2f9aae100a9caba688d31e410efb3444@localhost> References: <044.2f9aae100a9caba688d31e410efb3444@localhost> Message-ID: <053.71113c6250e6950a88a8e03111348163@localhost> #1136: High memory use when compiling many let bindings. ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:37:41 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:34:14 2008 Subject: [GHC] #1924: Rewrite the handling of values we get from ./configure In-Reply-To: <044.9ce32a75cdc46063892169755ff2cb07@localhost> References: <044.9ce32a75cdc46063892169755ff2cb07@localhost> Message-ID: <053.9e48e875ef9b0144362e8c8a50a3abff@localhost> #1924: Rewrite the handling of values we get from ./configure ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Build System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch Comment: I don't think this is worth doing mid-branch, so punting to 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:38:07 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:34:41 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.1ccc72a6b2af057c8d556085ee4b952b@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:39:28 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:36:00 2008 Subject: [GHC] #2297: Profiler is inconsistent about biography for GHC's heap In-Reply-To: <044.fbea862bca1709c4fb82e649273727f1@localhost> References: <044.fbea862bca1709c4fb82e649273727f1@localhost> Message-ID: <053.0356e7a557c025263d97b739510fd666@localhost> #2297: Profiler is inconsistent about biography for GHC's heap ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Profiling | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:44:10 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:40:54 2008 Subject: [GHC] #2647: Serious typo in IntMap.hs In-Reply-To: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> References: <048.d505c1b00186d62e3505b45367e8c9fe@localhost> Message-ID: <057.0a0a32b30ce2db73955b67cd8cfb4ea0@localhost> #2647: Serious typo in IntMap.hs -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries (other) | Version: 6.9 Severity: critical | Resolution: fixed Keywords: containers IntMap | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * version: 6.8.3 => 6.9 * resolution: => fixed * milestone: => 6.10.1 Comment: Like others have said, good spot; thanks! I've applied your patch to HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:50:56 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:47:28 2008 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@localhost> References: <045.82dbf1ade5f39047db873a9122708a49@localhost> Message-ID: <054.16069d519431c4f2bb6dbc2807be05c9@localhost> #149: missed CSE opportunity --------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 5.04.2 Severity: minor | Resolution: None Keywords: optimisations | Difficulty: Moderate (1 day) Testcase: simplrun006 | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:51:17 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:47:56 2008 Subject: [GHC] #783: performance problem compiling large file In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost> References: <044.a7a580fed8a85952633cd84570dae070@localhost> Message-ID: <053.fa8fc2f8fd1f47641c8e79ce96c969f7@localhost> #783: performance problem compiling large file ------------------------------------------+--------------------------------- Reporter: guest | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:53:32 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:50:06 2008 Subject: [GHC] #1216: indexing 2d arrays is slow and leaky. why? In-Reply-To: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> References: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> Message-ID: <053.ce4eaacb63b3353caf0051fa6d8ca5ed@localhost> #1216: indexing 2d arrays is slow and leaky. why? --------------------------------------+------------------------------------- Reporter: claus | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:54:10 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:50:47 2008 Subject: [GHC] #1293: building ghc 6.8.3 hangs on sparc solaris at Language/Haskell/Syntax.hs In-Reply-To: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> References: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> Message-ID: <050.6af90ca659ccfa43900f6629c4f88b86@localhost> #1293: building ghc 6.8.3 hangs on sparc solaris at Language/Haskell/Syntax.hs -------------------------------+-------------------------------------------- Reporter: mm | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: hangs compilation | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:54:47 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:51:22 2008 Subject: [GHC] #1434: Slow conversion from Double to Int In-Reply-To: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> References: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> Message-ID: <073.e7d0c19527eb36c07fe16218970f8e93@localhost> #1434: Slow conversion from Double to Int ---------------------------------------+------------------------------------ Reporter: ghc@henning-thielemann.de | Owner: dons Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: rules | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Linux | ---------------------------------------+------------------------------------ Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:55:04 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:51:36 2008 Subject: [GHC] #1605: hppa port -- gmp handed misaligned memory In-Reply-To: <044.7ca61f85138b90c0e193b83a232b3207@localhost> References: <044.7ca61f85138b90c0e193b83a232b3207@localhost> Message-ID: <053.f8c8b8459a8df306da0b6426aaef5dc8@localhost> #1605: hppa port -- gmp handed misaligned memory ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: GMP | Difficulty: Easy (1 hr) Testcase: | Architecture: hppa Os: HPUX | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:55:14 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:51:46 2008 Subject: [GHC] #1820: Windows segfault-catching only works for the main thread In-Reply-To: <047.7ca539e672ab08a35be7d52badf17eec@localhost> References: <047.7ca539e672ab08a35be7d52badf17eec@localhost> Message-ID: <056.4b4fe48a02370a3c3aef0d90071cf239@localhost> #1820: Windows segfault-catching only works for the main thread ----------------------------------------------+----------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: derefnull(ghci), divbyzero(ghci) | Architecture: Unknown/Multiple Os: Windows | ----------------------------------------------+----------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:57:03 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:53:35 2008 Subject: [GHC] #1870: ghc-6.8.1 panics compiling regex-tdfa-0.93 In-Reply-To: <053.ed75b86fd46ffdb671ac3109a1855225@localhost> References: <053.ed75b86fd46ffdb671ac3109a1855225@localhost> Message-ID: <062.b87380e994d18deb8a6180d33c4df024@localhost> #1870: ghc-6.8.1 panics compiling regex-tdfa-0.93 ------------------------------+--------------------------------------------- Reporter: ChrisKuklewicz | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:57:19 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:53:52 2008 Subject: [GHC] #1944: round function causes cblas NaNs In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> Message-ID: <061.7a3ef350e170009e9db5e00bcf9e7f98@localhost> #1944: round function causes cblas NaNs ---------------------------+------------------------------------------------ Reporter: SevenThunders | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------+------------------------------------------------ Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 07:57:33 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 07:54:05 2008 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.1e787b11ffa812a6e73b79d60d6550e9@localhost> #1969: enormous compile times ------------------------------------------+--------------------------------- Reporter: duncan | Owner: igloo Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 08:04:51 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 08:01:25 2008 Subject: [GHC] #2147: unhelpful error message for a misplaced DEPRECATED pragma In-Reply-To: <044.4706a1b0e36567a842f434c8ed45f7f6@localhost> References: <044.4706a1b0e36567a842f434c8ed45f7f6@localhost> Message-ID: <053.3ff246d383f63a2b62358b8b1fec1f09@localhost> #2147: unhelpful error message for a misplaced DEPRECATED pragma ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 08:06:37 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 08:03:11 2008 Subject: [GHC] #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.0319b244afc481b7cfc7058f7a90c2fc@localhost> #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP --------------------------------------------+------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 08:07:54 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 08:04:27 2008 Subject: [GHC] #2193: Monomorphic Pattern Bindings and Error Messages In-Reply-To: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> References: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> Message-ID: <052.968ca645905c4303172f7858e9d25e39@localhost> #2193: Monomorphic Pattern Bindings and Error Messages ------------------------------+--------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 08:08:16 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 08:04:50 2008 Subject: [GHC] #2270: gcd is specialised only for Int In-Reply-To: <043.b1b4c47bccdeb536ea28564b64a56127@localhost> References: <043.b1b4c47bccdeb536ea28564b64a56127@localhost> Message-ID: <052.fd216fbcd134b0ad1483fc8af92ce881@localhost> #2270: gcd is specialised only for Int ---------------------------------------------+------------------------------ Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: rules, performance, double, gcd | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 08:08:37 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 08:05:10 2008 Subject: [GHC] #2271: floor, ceiling, round :: Double -> Int are awesomely slow In-Reply-To: <043.845265305898c52232b3689d70d3b99c@localhost> References: <043.845265305898c52232b3689d70d3b99c@localhost> Message-ID: <052.de5288babca235a20a99d5b026fa6b44@localhost> #2271: floor, ceiling, round :: Double -> Int are awesomely slow ---------------------------------------+------------------------------------ Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: performance, math, double | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ---------------------------------------+------------------------------------ Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 08:10:01 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 08:06:41 2008 Subject: [GHC] #2282: threaded runtime system crashes on powerpc with -N2 In-Reply-To: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> References: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> Message-ID: <077.2a69a6f48029506bdd1b3b8427b1039b@localhost> #2282: threaded runtime system crashes on powerpc with -N2 -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------------------------+-------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 08:16:57 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 08:13:31 2008 Subject: [GHC] #2300: GHCi locks up on long input In-Reply-To: <042.b8baab5f9560c1bc1ba314b7db87b0d2@localhost> References: <042.b8baab5f9560c1bc1ba314b7db87b0d2@localhost> Message-ID: <051.8d23fcad3f1608d92eaa72892d993966@localhost> #2300: GHCi locks up on long input --------------------+------------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: If you are still seeing this problem with 6.10, please re-open this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 08:17:57 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 08:14:29 2008 Subject: [GHC] #2346: Compilation of large source files requires a lot of RAM In-Reply-To: <046.285595109907aedbac69f385749bac00@localhost> References: <046.285595109907aedbac69f385749bac00@localhost> Message-ID: <055.c39236638d75058b8419c96d6506dc34@localhost> #2346: Compilation of large source files requires a lot of RAM ------------------------------------------+--------------------------------- Reporter: choener | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 09:06:55 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 09:03:29 2008 Subject: [GHC] #2653: Hugs does not like bracketOnError in Network.hs Message-ID: <049.c4a045d4c7e30d0cb074380d297bd531@localhost> #2653: Hugs does not like bracketOnError in Network.hs ---------------------------------+------------------------------------------ Reporter: golubovsky | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.8.3 | Severity: major Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Currently network/Network.hs has this: {{{ -- Utils #if __GLASGOW_HASKELL__ < 606 -- Like bracket, but only performs the final action if there was an -- exception raised by the middle bit. bracketOnError :: IO a -- ^ computation to run first (\"acquire resource\") -> (a -> IO b) -- ^ computation to run last (\"release resource\") -> (a -> IO c) -- ^ computation to run in-between -> IO c -- returns the value from the in-between computation bracketOnError before after thing = Exception.block (do a <- before r <- Exception.catch (Exception.unblock (thing a)) (\e -> do { after a; Exception.throw e }) return r ) #else bracketOnError = Exception.bracketOnError #endif }}} So Hugs gets the <606 definition which it does not like (type error printed on bracketOnError). {{{ runhugs: Error occurred ERROR "/home2/dima/install/hugs98/hugsdir/packages/network/Network.hs":511 - Cannot justify constraints in explicitly typed binding *** Expression : bracketOnError *** Type : IO a -> (a -> IO b) -> (a -> IO c) -> IO c *** Given context : () *** Constraints : Exception d }}} This can be fixed by adding `&& !__HUGS__` to the #if line. That is (darcs whatsnew), {{{ { hunk ./Network.hs 378 -#if __GLASGOW_HASKELL__ < 606 +#if __GLASGOW_HASKELL__ < 606 && !__HUGS__ } }}} so Hugs gets the second definition (redirected to Exception.bracketOnError) which works. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 09:16:48 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 09:13:20 2008 Subject: [GHC] #2653: Hugs does not like bracketOnError in Network.hs In-Reply-To: <049.c4a045d4c7e30d0cb074380d297bd531@localhost> References: <049.c4a045d4c7e30d0cb074380d297bd531@localhost> Message-ID: <058.54e102d9eff6410b3eb9cd168b1bf925@localhost> #2653: Hugs does not like bracketOnError in Network.hs ----------------------------------+----------------------------------------- Reporter: golubovsky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/network | Version: 6.8.3 Severity: major | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------+----------------------------------------- Comment (by golubovsky): PS Please consider patching the recenfly forked 6.10 branch as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 09:29:23 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 09:25:57 2008 Subject: [GHC] #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 In-Reply-To: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> References: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> Message-ID: <062.7d9ac5a83f61ee7241dd2a737f1d99c8@localhost> #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 -----------------------------------------------+---------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: simplCore/should_compile/simpl014 | Architecture: Unknown/Multiple Os: MacOS X | -----------------------------------------------+---------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 09:35:40 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 09:32:16 2008 Subject: [GHC] #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin In-Reply-To: <047.918ccc59a875951e79ffd2348c4375d6@localhost> References: <047.918ccc59a875951e79ffd2348c4375d6@localhost> Message-ID: <056.084b0c2f54f97ea9404fe1c91b361a88@localhost> #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin ------------------------------+--------------------------------------------- Reporter: jimwhite | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Reporter now can't reproduce the problem any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 09:39:20 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 09:35:55 2008 Subject: [GHC] #2443: @EnableWin32DLLs@ in mk/config.mk In-Reply-To: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@localhost> References: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@localhost> Message-ID: <054.fb6eb3c823ad1b97643c60b933e38e96@localhost> #2443: @EnableWin32DLLs@ in mk/config.mk ------------------------------+--------------------------------------------- Reporter: rurban | Owner: rurban Type: bug | Status: assigned Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 09:41:21 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 09:37:52 2008 Subject: [GHC] #2476: internal error: awaitEvent: descriptor out of range In-Reply-To: <046.98b2024ece2c4d6cefc902a4a054a14b@localhost> References: <046.98b2024ece2c4d6cefc902a4a054a14b@localhost> Message-ID: <055.24e679e1df46ebf6c4a5766b26b174a7@localhost> #2476: internal error: awaitEvent: descriptor out of range ----------------------------+----------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: ia64 Os: FreeBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 09:55:50 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 09:52:25 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.f9a0ed0645dbfde162bcb399a5f9e34f@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ---------------------+------------------------------------------------------ Changes (by igloo): * milestone: 6.10.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 09:56:19 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 09:53:02 2008 Subject: [GHC] #2510: Environment modification during installation should be optional In-Reply-To: <045.3e84f679ca4e95a8a9ec350bbb64b495@localhost> References: <045.3e84f679ca4e95a8a9ec350bbb64b495@localhost> Message-ID: <054.4f8edb594fb8d7203741d42f9d91d7e6@localhost> #2510: Environment modification during installation should be optional -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 09:57:03 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 09:53:35 2008 Subject: [GHC] #2512: MAP_32BIT flag might not be respected under xen? In-Reply-To: <044.02579c65234b2e00edf9fbae992e571c@localhost> References: <044.02579c65234b2e00edf9fbae992e571c@localhost> Message-ID: <053.d68d42a9719bd4bf0e1ee0434ab3d135@localhost> #2512: MAP_32BIT flag might not be respected under xen? ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: None | Version: 6.8.3 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 10:03:28 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 10:00:05 2008 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.23eec837d8a5580ce04f239d0a069f23@localhost> #2578: "ld: atom sorting error for ..." on OS X ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 10:04:17 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 10:00:49 2008 Subject: [GHC] #2592: Can't profile when the heap maximum is hit In-Reply-To: <046.6ff10d2040e94a9b4e4cc6a778189212@localhost> References: <046.6ff10d2040e94a9b4e4cc6a778189212@localhost> Message-ID: <055.c290ddc63bae81b6a37c42022556a8a1@localhost> #2592: Can't profile when the heap maximum is hit ---------------------------+------------------------------------------------ Reporter: adekoba | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: profile, heap | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Linux | ---------------------------+------------------------------------------------ Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 10:04:31 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 10:01:03 2008 Subject: [GHC] #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` In-Reply-To: <043.429d5e175a90219c9682c6f3937cb586@localhost> References: <043.429d5e175a90219c9682c6f3937cb586@localhost> Message-ID: <052.c86f4bbb701c2135ba0971f048db0578@localhost> #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` ------------------------------+--------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 10:04:44 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 10:01:15 2008 Subject: [GHC] #2628: isatty behaves unexpectedly on mingw In-Reply-To: <044.c1bd1c3ac0471340a6fae29b24f965a3@localhost> References: <044.c1bd1c3ac0471340a6fae29b24f965a3@localhost> Message-ID: <053.7d4deb642f208eff16b7bdd4931a0a5d@localhost> #2628: isatty behaves unexpectedly on mingw ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: 2228 | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 10:05:43 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 10:02:15 2008 Subject: [GHC] #1747: debugger: :trace is wasting time In-Reply-To: <047.b9bb4088c80d0d5b1d518a14686f3b5c@localhost> References: <047.b9bb4088c80d0d5b1d518a14686f3b5c@localhost> Message-ID: <056.7edcc384b74d8d355b33e486ef247a5a@localhost> #1747: debugger: :trace is wasting time ------------------------------------------+--------------------------------- Reporter: simonmar | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * priority: low => normal * milestone: 6.10.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 10:06:19 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 10:02:51 2008 Subject: [GHC] #2226: duplicate samples in heap profiling (-hc) output on 6.8.2 In-Reply-To: <046.1e179a2ccae41d3a00bbbbb417b91596@localhost> References: <046.1e179a2ccae41d3a00bbbbb417b91596@localhost> Message-ID: <055.ea2f34fcb76681cca6b3c4c6e13e0fb9@localhost> #2226: duplicate samples in heap profiling (-hc) output on 6.8.2 ------------------------------+--------------------------------------------- Reporter: clemens | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.12 branch Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 10:08:22 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 10:04:53 2008 Subject: [GHC] #2653: Hugs does not like bracketOnError in Network.hs In-Reply-To: <049.c4a045d4c7e30d0cb074380d297bd531@localhost> References: <049.c4a045d4c7e30d0cb074380d297bd531@localhost> Message-ID: <058.41125605d60f0af182f5cf62da2c25dd@localhost> #2653: Hugs does not like bracketOnError in Network.hs ----------------------------------+----------------------------------------- Reporter: golubovsky | Owner: Type: merge | Status: new Priority: normal | Milestone: Component: libraries/network | Version: 6.8.3 Severity: major | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------+----------------------------------------- Changes (by ross): * type: bug => merge Comment: fixed in HEAD. This was yet another #if __GLASGOW_HASKELL__ < nnn which also succeeds for non-GHCs, and should be #if __GLASGOW_HASKELL__ && __GLASGOW_HASKELL__ < nnn Please merge to 6.10, so that other impls can use the version released with GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 10:13:52 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 10:10:25 2008 Subject: [GHC] #2653: Hugs does not like bracketOnError in Network.hs In-Reply-To: <049.c4a045d4c7e30d0cb074380d297bd531@localhost> References: <049.c4a045d4c7e30d0cb074380d297bd531@localhost> Message-ID: <058.3ccef1eb6fbf83de6688de05487443b7@localhost> #2653: Hugs does not like bracketOnError in Network.hs -------------------------------+-------------------------------------------- Reporter: golubovsky | Owner: Type: merge | Status: closed Priority: normal | Milestone: Component: libraries/network | Version: 6.8.3 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: network (extralibs) isn't forked, so no need to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 10:28:09 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 10:24:42 2008 Subject: [GHC] #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow In-Reply-To: <044.75a109ff49643f020ff0241cedbdd8c4@localhost> References: <044.75a109ff49643f020ff0241cedbdd8c4@localhost> Message-ID: <053.7f9904525d2b7ab1197406f4bb4d0f91@localhost> #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow --------------------------------------+------------------------------------- Reporter: igloo | Owner: igloo Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 13:07:48 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 13:04:20 2008 Subject: [GHC] #2654: pwd problems Message-ID: <042.fe387cccf0837a5597d31d502fc3d236@localhost> #2654: pwd problems ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ When compiling today's darcs HEAD, I repeatedly get error messages: {{{ Bad args: [] Usage: pwd {forwardslash|quadruple-backslash} }}} This doesn't appear to affect the build in any way, but it is a bit worrying. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 13:21:30 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 13:18:04 2008 Subject: [GHC] #2654: pwd problems In-Reply-To: <042.fe387cccf0837a5597d31d502fc3d236@localhost> References: <042.fe387cccf0837a5597d31d502fc3d236@localhost> Message-ID: <051.915275a5efa8e0b2a2dec6791fdcd6af@localhost> #2654: pwd problems ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: I don't see this. Can you give some more detail please, e.g.: What platform are you on? What are the lines around the errors? What do {{{ pwd }}} {{{ which pwd }}} and {{{ type pwd }}} say? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 14:14:43 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 14:11:15 2008 Subject: [GHC] #2654: pwd problems In-Reply-To: <042.fe387cccf0837a5597d31d502fc3d236@localhost> References: <042.fe387cccf0837a5597d31d502fc3d236@localhost> Message-ID: <051.2983b152ceb8d344f8263269260cfe0f@localhost> #2654: pwd problems ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by ajd): Actually, this may have been a problem with my system pwd, which was changed by installing ghc-6.9.20080825 (that installation put the GHC pwd in my path). I'll check after the compilation finishes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 15:38:39 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 15:35:12 2008 Subject: [GHC] #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow In-Reply-To: <044.75a109ff49643f020ff0241cedbdd8c4@localhost> References: <044.75a109ff49643f020ff0241cedbdd8c4@localhost> Message-ID: <053.3322ee080d4903b505510faaff791b84@localhost> #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow --------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * owner: igloo => * milestone: 6.10.1 => 6.12 branch Comment: I've fixed magnitude, but we might still want to add the RULE. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 15:55:46 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 15:52:23 2008 Subject: [GHC] #2585: New versions of windres fail with "windres: CreateProcess (null): No error" In-Reply-To: <044.25b69fd7b594ae443d31576c538df3be@localhost> References: <044.25b69fd7b594ae443d31576c538df3be@localhost> Message-ID: <053.f032c0696e8b992f866da1bfcf37e572@localhost> #2585: New versions of windres fail with "windres: CreateProcess (null): No error" ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We now check for bad versions. both in configure, and when preparing a bindist. Patches in both HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 16:57:45 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 16:54:17 2008 Subject: [GHC] #2560: killThread and getChanContents appear to interact strangely In-Reply-To: <053.7b90af27065da85db72f8f049c3b99b1@localhost> References: <053.7b90af27065da85db72f8f049c3b99b1@localhost> Message-ID: <062.caa964d9db7f26db01a046d285b47c2a@localhost> #2560: killThread and getChanContents appear to interact strangely ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * os: MacOS X => Unknown/Multiple * architecture: x86 => Unknown/Multiple * milestone: => 6.10.2 Comment: I can reproduce this on amd64/Linux too, and with 6.8.2 as well as the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 17:36:42 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 17:33:15 2008 Subject: [GHC] #2608: Direct support for unit tests in Cabal In-Reply-To: <043.0f910c87967bdcd72df76a06d6dc0fa6@localhost> References: <043.0f910c87967bdcd72df76a06d6dc0fa6@localhost> Message-ID: <052.bece827429a74aef812026a797f661d6@localhost> #2608: Direct support for unit tests in Cabal -------------------------------+-------------------------------------------- Reporter: kaol | Owner: Type: proposal | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 18:30:30 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 18:27:01 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.615a8acc2a1ccf50eaf48215b0b73cd2@localhost> #2497: Weird scoping for tyvars in rules --------------------------------------------+------------------------------- Reporter: rl | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2497 | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by duncan): * status: closed => reopened * resolution: fixed => Comment: Replying to [comment:4 simonpj]: It's not entirely obvious to me that this is all fixed, in particular this point: > * Inside a RULE, switch on `-XScopedTypeVariables` unconditionally. I'm using ghc-6.10.0.20080927 and updating bytestring to use `LANGUAGE` pragmas rather than `-fglasgow-exts`. Without adding `ScopedTypeVariables` I get errors for the `RULES` pragmas: {{{ Data/ByteString.hs:453:30: Not in scope: `forall' Data/ByteString.hs:453:37: Not in scope: `p' }}} This is complaining about the code: {{{ {-# RULES "ByteString unpack-list" [1] forall p . unpackFoldr p (:) [] = unpackList p #-} }}} It's not clear to me what the "Right Thing" I'm supposed to do. Should I be using the `ScopedTypeVariables` to get `RULES` pragmas to be recognised? Do I need to use `-fuse-rewrite-rules` to have the rules actually used? What should I be using for older ghc? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 18:32:41 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 18:29:13 2008 Subject: [GHC] #2608: Direct support for unit tests in Cabal In-Reply-To: <043.0f910c87967bdcd72df76a06d6dc0fa6@localhost> References: <043.0f910c87967bdcd72df76a06d6dc0fa6@localhost> Message-ID: <052.0ad92c9ad71325a13ba2723eef30d930@localhost> #2608: Direct support for unit tests in Cabal -------------------------------+-------------------------------------------- Reporter: kaol | Owner: Type: proposal | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Comment (by duncan): This should be filed in the Cabal bug tracker. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 18:46:14 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 18:42:44 2008 Subject: [GHC] #2654: pwd problems In-Reply-To: <042.fe387cccf0837a5597d31d502fc3d236@localhost> References: <042.fe387cccf0837a5597d31d502fc3d236@localhost> Message-ID: <051.543781d12e9ca4e76dc6b078117f0c76@localhost> #2654: pwd problems ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by ajd): Okay, so I've got the information now. It is a problem with the system pwd, but that problem is caused by GHC, so I think it's still a bug. After I installed today's head with {{{ PREFIX=/usr/local }}}, a binary called "pwd" was installed into /usr/local/bin. When I typed make again inside the GHC source tree, the first lines of output were {{{ Bad args: [] Usage: pwd {forwardslash|quadruple-backslash} Bad args: [] Usage: pwd {forwardslash|quadruple-backslash} }}} When I remove /usr/local/bin/pwd (thereby making the first pwd in the PATH /bin/pwd), there were no warnings. I am on i686 linux. type pwd says shell builtin, which pwd says /usr/local/bin/pwd. So I think that GHC should not install its own pwd, at least not into the public binaries directory. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 18:58:53 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 18:55:24 2008 Subject: [GHC] #2654: pwd problems In-Reply-To: <042.fe387cccf0837a5597d31d502fc3d236@localhost> References: <042.fe387cccf0837a5597d31d502fc3d236@localhost> Message-ID: <051.b07a3984292161e98adbc12572e1603f@localhost> #2654: pwd problems ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by igloo): Hmm, that shouldn't be happening. When you say "today's head", do you mean a darcs checkout, or what? In the tree you installed from, do you have a line {{{ DO_NOT_INSTALL = pwd installPackage }}} in `utils/Makefile`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 4 19:30:42 2008 From: trac at galois.com (GHC) Date: Sat Oct 4 19:27:16 2008 Subject: [GHC] #2654: pwd problems In-Reply-To: <042.fe387cccf0837a5597d31d502fc3d236@localhost> References: <042.fe387cccf0837a5597d31d502fc3d236@localhost> Message-ID: <051.63af7591e3cbb851ef1b28ca900478ff@localhost> #2654: pwd problems ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by ajd): * status: new => closed * resolution: => invalid Comment: Whoops, never mind. I guess I didn't properly remove the pwd from the old GHC installation or something...I thought I had chmod -x'd it, but I guess not. This doesn't seem to be a problem; sorry for the inconvenience. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 07:20:54 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 07:17:24 2008 Subject: [GHC] #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions Message-ID: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions ---------------------------------+------------------------------------------ Reporter: shelarcy | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ GHC 6.10.1 beta replaced old Control.Exception module by Extensible Exceptions. But Control.Exception module doesn't have any instruction about Extensible Exceptions now. Description doesn't have imformation about "An Extensible Dynamically- Typed Hierarchy of Exceptions". There is no imformation and example about Extensible exception's new fuctions and types. So, people can't switch to new exception library easily. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 07:22:37 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 07:19:12 2008 Subject: [GHC] #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions In-Reply-To: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> References: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> Message-ID: <056.e81269f73cdf393a21d7959e13e1790e@localhost> #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions ---------------------------------+------------------------------------------ Reporter: shelarcy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by shelarcy): * cc: shelarcy@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 07:36:01 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 07:32:32 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.1e165d8991c062c40b0d20ecd6985115@localhost> #2337: Data.Array documentation utterly broken ------------------------------+--------------------------------------------- Reporter: japple | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by waern): * cc: david.waern@gmail.com (added) * version: 6.8.3 => 6.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 08:52:25 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 08:48:58 2008 Subject: [GHC] #2656: GHC API document isn't linked from any document Message-ID: <047.e27d233da8925cb230afc995997360c3@localhost> #2656: GHC API document isn't linked from any document ---------------------------------+------------------------------------------ Reporter: shelarcy | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ GHC 6.10.1 beta binay distribution has GHC API Haddock document. But it doesn't linked from either top of GHC document or Libraries document, now. So, we can't find it easily. One problem is that GHC API isn't hierarchical modules now. So, linking from Libraries document is a bad solution. Does anybody has good ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 09:04:49 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 09:01:19 2008 Subject: [GHC] #2657: DPH Haddock document isn't linked from Libraries document Message-ID: <047.3ea7891160068f161ef63cd3e40d298b@localhost> #2657: DPH Haddock document isn't linked from Libraries document ---------------------------------+------------------------------------------ Reporter: shelarcy | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ GHC 6.10.1 beta binay distribution has DPH libraries(dph-* packages)' Haddock document. But it isn't linked from Libraries document. So, we can't find it easily. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 10:21:00 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 10:17:30 2008 Subject: [GHC] #2658: Extreme memory usage Message-ID: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> #2658: Extreme memory usage -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: major Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- This is with the ghc 6.10.1 rc: http://darcs.haskell.org/ghc-STABLE-2008-09-19-ghc-corelibs- testsuite.tar.bz2, unpacked, then ./darcs-all --extra get and ./darcs-all pull -a Then a perf build. Then, wget http://hackage.haskell.org/packages/archive/sessions/2008.7.18/sessions-2008.7.18.tar.gz, unpack and cd sessions-2008.7.18 ghci-6.8.3 Tests/Tests.hs. This takes 40 seconds to get to the prompt and uses about 700MB memory. ghci-6.10.0.20081004 Tests/Tests.hs. This has not finished type checking yet (well over 5 mins now - it exhaused my 4GB RAM and is now eating its way through 16GB of swap). top reports it's currently using about 5GB memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 10:23:56 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 10:20:25 2008 Subject: [GHC] #2658: Extreme memory usage In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.acbc7ca7472724e438fd5811b93ae50c@localhost> #2658: Extreme memory usage ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux ----------------------------------------+----------------------------------- Comment (by guest): Oh bother, I forgot to add that you'll either need to install Data.Binary or just comment out the import and export of Control.Concurrent.Session.Network.Socket in Control/Concurrent/Session.hs. I just commented it out in my tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 10:27:06 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 10:23:35 2008 Subject: [GHC] #2658: Extreme memory usage In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.d51b58daf9615176311888dafa886781@localhost> #2658: Extreme memory usage ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux ----------------------------------------+----------------------------------- Changes (by guest): * cc: matthew@wellquite.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 11:27:28 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 11:23:56 2008 Subject: [GHC] #2659: Add sortBy and other *By functions Message-ID: <045.d1e80fa0049c474f9074e278f7023d7a@localhost> #2659: Add sortBy and other *By functions ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Almost all uses of {{{sortBy}}} are of the form {{{sortBy (comparing f)}}}, {{{sortBy (compare `on` f)}}} or an equivalent construction. I propose that we add the more convenient function {{{sortOn}}} to Data.List: {{{ sortOn :: Ord b => (a -> b) -> [a] -> [a] }}} For consistency for the other `By` functions we should also add an `On` equivalent: {{{ nubOn :: Eq b => (a -> b) -> [a] -> [a] deleteOn :: Eq b => (a -> b) -> a -> [a] -> [a] deleteFirstsOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] unionOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] intersectOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] groupOn :: Eq b => (a -> b) -> [a] -> [[a]] sortOn :: Ord b => (a -> b) -> [a] -> [a] insertOn :: Ord b => (a -> b) -> a -> [a] -> [a] maximumOn :: Ord b => (a -> b) -> [a] -> a minimumOn :: Ord b => (a -> b) -> [a] -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 11:37:16 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 11:33:46 2008 Subject: [GHC] #2660: Add Down newtype wrapper for reversing orderings Message-ID: <045.b364667488af4fd3b8ece4ea98fa954f@localhost> #2660: Add Down newtype wrapper for reversing orderings ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ In the same spirit as the newtypes in Data.Monoid, we can also add a newtype for reversing the ordering of a type: {{{ newtype Down a = Down { getDown :: a } instance Ord a => Ord (Down a) where Down x < Down y = y < x -- etc. }}} This newtype is especially useful in combination with `sortOn` (ticket #2629). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 11:41:03 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 11:37:32 2008 Subject: [GHC] #2659: Add sortOn and other *On functions In-Reply-To: <045.d1e80fa0049c474f9074e278f7023d7a@localhost> References: <045.d1e80fa0049c474f9074e278f7023d7a@localhost> Message-ID: <054.524ddf3933bb26d610e2aa9b53b555ce@localhost> #2659: Add sortOn and other *On functions ------------------------------+--------------------------------------------- Reporter: twanvl | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * summary: Add sortBy and other *By functions => Add sortOn and other *On functions * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 11:59:50 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 11:56:21 2008 Subject: [GHC] #2406: Data.List.sortFun In-Reply-To: <046.08859d63266a4054020b2d26eaa3a7a5@localhost> References: <046.08859d63266a4054020b2d26eaa3a7a5@localhost> Message-ID: <055.78bc4c61d0837cb1f696525114292fde@localhost> #2406: Data.List.sortFun ------------------------------+--------------------------------------------- Reporter: lpsmith | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by guest): See ticket:2659 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 12:32:37 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 12:29:07 2008 Subject: [GHC] #2658: Extreme memory usage In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.c55ee5165d4732dc2600c5f0ecdabcea@localhost> #2658: Extreme memory usage ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux ----------------------------------------+----------------------------------- Comment (by guest): I remembered that I had access to a machine with 8GB RAM and 4GB swap. After 3 mins, the 6.10 rc had eaten the 8GB RAM and I killed it when it hit 10GB usage total. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 15:07:57 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 15:04:26 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.67403a58087c7ed9c3199284eaae5730@localhost> #2081: GHC reports internal error: stg_ap_v_ret ------------------------------+--------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by thorkilnaur): After discussing this briefly on #ghc the other day, I tried to get back to the version of the HEAD that had the problem, but I failed to reproduce it. However, the two subsequent buildbot builds both have the problem (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/142 and http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20stable%202/builds/179). And I am able to consistently reproduce the problem mentioned above with the timeout program. So the question is, how to proceed. Compiling with -O2 and running with +RTS -DSs produces: {{{ $ ./timeout 200 "echo Something" +RTS -DSs new task (taskCount: 1) task exiting new task (taskCount: 1) created thread 1, stack size = f1 words new bound thread (1) ### NEW SCHEDULER LOOP (task: 0x600520, cap: 0x2a1178) -->> running thread 1 ThreadRunGHC ... created thread 2, stack size = f1 words created thread 3, stack size = f1 words --<< thread 1 (ThreadRunGHC) stopped: is blocked on an MVar @ 0x117f370 -->> running thread 2 ThreadRunGHC ... --<< thread 2 (ThreadRunGHC) stopped, yielding -->> running thread 3 ThreadRunGHC ... thread 3 did a safe foreign call forking! new task (taskCount: 2) task exiting thread 3: re-entering RTS timeout: internal error: stg_ap_p_ret (GHC version 6.11.20081003 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug waking up thread 3 on cap 0 raising exception in thread 2. raising exception in thread 1. discarding task 6292768 created thread 4, stack size = f1 words new bound thread (4) ### NEW SCHEDULER LOOP (task: 0x6005f0, cap: 0x2a1178) -->> running thread 4 ThreadRunGHC ... Something Abort trap $ }}} But I am sorely in need of some hints. Another possibility would be for some seasoned expert to get access to the machinery and take a look. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 15:46:43 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 15:43:11 2008 Subject: [GHC] #2661: Associated type synonyms not fully simplified in GHCi Message-ID: <045.1a887192f106b18bef3be47f87026bff@localhost> #2661: Associated type synonyms not fully simplified in GHCi -----------------------+---------------------------------------------------- Reporter: kupopo | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- The following code works as expected when compiled in GHC, or even when loaded into GHCi and run with "main": {{{ {-# LANGUAGE TypeFamilies, MultiParamTypeClasses, FlexibleContexts #-} data Z = Z data S n = S n class Peano n where mkPeano :: n toInt :: n -> Int instance Peano Z where mkPeano = Z toInt Z = 0 instance Peano n => Peano (S n) where mkPeano = S mkPeano toInt (S n) = 1 + toInt n class (Peano a, Peano b, Peano (Sum a b)) => BinOp a b where type Sum a b instance BinOp Z Z where type Sum Z Z = Z instance Peano a => BinOp Z (S a) where type Sum Z (S a) = S a instance Peano a => BinOp (S a) Z where type Sum (S a) Z = S a instance BinOp a b => BinOp (S a) (S b) where type Sum (S a) (S b) = S (S (Sum a b)) add :: BinOp a b => a -> b -> Sum a b add _ _ = mkPeano main = do print $ toInt $ add Z $ add Z Z }}} However, if the contents of main is typed at the GHCi prompt (toInt $ add Z $ add Z Z), it complains that {{{No instance for (BinOp Z (Sum Z Z)) arising from a use of `add' at :1:8-12}}}. Evidently it stops short before evaluating that Sum Z Z = Z and therefore BinOp Z Z is in fact an instance. This is the case both in 6.8.3 as well as 6.10.0.20080921. If "seq 1" is inserted, as in "toInt $ seq 1 $ add Z $ add Z Z", then GHCi again behaves consistently with GHC. This is therefore a workaround, albeit inconvenient. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 16:44:16 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 16:40:48 2008 Subject: [GHC] #2658: Extreme memory usage In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.b0b66071c8b065b99d0c03c4a92cc682@localhost> #2658: Extreme memory usage ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux ----------------------------------------+----------------------------------- Comment (by guest): I've also just checked this on GHC head and it's the same behaviour, exhausting RAM and then going nowhere fast as it swaps endlessly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 19:13:56 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 19:10:24 2008 Subject: [GHC] #2659: Add sortOn and other *On functions In-Reply-To: <045.d1e80fa0049c474f9074e278f7023d7a@localhost> References: <045.d1e80fa0049c474f9074e278f7023d7a@localhost> Message-ID: <054.e924621fb724cf7f02cacc0895d1b769@localhost> #2659: Add sortOn and other *On functions ------------------------------+--------------------------------------------- Reporter: twanvl | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by lpsmith): I think the {{{sortOn}}} suggestion is a good one. Honestly, the need to import to import two libraries *and then* use the {{{sortBy (comparing someFunctionName)}}} idiom is rather cumbersome for something so useful, absurdly so if you use qualified names. (I tend to use qualified names.) "sortOn" is a good name as well, much better than my suggested "sortFun". (ticket:2406) However, I'm a bit ambivalent towards the other suggestions. Take {{{maximumOn}}}. What would elements would the following examples return? {{{ maximumOn abs [-30, 4, 8, 30] maximumOn abs [ 30, 4, 8, -30] }}} I suppose this function is supposed to be equivalent to {{{maximumBy (comparing abs)}}}, but I wouldn't know what this does off the top of my head. I would guess that it returns the "first" maximum, -30 and 30 respectively in the example. But the documentation is incomplete: I'd have to look at the sources to be absolutely sure of what this function does. The thing is, {{{maximumBy}}} returns the maximum element in some quotient type; essentially re-defining ordering (and possibly equality) in the result, something I don't find to be particularly useful. However, {{{sortBy}}} still has nice properties without referring to the quotient type: I'm guaranteed some kind of permutation that interests me, assuming that the comparison function is indeed a total linear order. However, I do find the functions {{{maximalsOn}}} and {{{maximalsBy}}} to be rather useful, which evaluate as follows: {{{ maximalsOn abs [-30, 4, 8, 30] == [-30, 30] maximalsOn abs [30, 4, 8, -30] == [30, -30] maximalsOn abs [30, 4, 30, 8, -30] == [30, 30, -30] maximalsOn abs [] == [] }}} This has the advantage of being defined on empty lists too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 19:23:29 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 19:19:57 2008 Subject: [GHC] #2406: Data.List.sortFun In-Reply-To: <046.08859d63266a4054020b2d26eaa3a7a5@localhost> References: <046.08859d63266a4054020b2d26eaa3a7a5@localhost> Message-ID: <055.168dfcfd9079279f42ae42c87af66971@localhost> #2406: Data.List.sortFun ------------------------------+--------------------------------------------- Reporter: lpsmith | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by lpsmith): There is no semantic difference between the two functions. However, there are runtime tradeoffs. After all, given {{{sortFun f list}}}, {{{f}}} will get called approximately {{2 * n * log n)}}} times, where n is the length of {{{list}}}. Of course, the number of times it gets called per element depends on the sorting algorithm and the initial permutation of the list. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 5 22:57:33 2008 From: trac at galois.com (GHC) Date: Sun Oct 5 22:54:01 2008 Subject: [GHC] #2662: should install ghc-pkg with versioned name again Message-ID: <045.4fbb042a5339b9b4bf5b3eb5b9339eb1@localhost> #2662: should install ghc-pkg with versioned name again ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Component: Build System Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Linux ---------------------------------+------------------------------------------ The build system has always installed ghc and ghc-pkg as a link to ghc-x.y and ghc-pkg-x.y on unix systems. In the current ghc-6.10 builds this is only done for ghc and ghci, not for ghc-pkg. It should be done for both. It's very useful for people who install multiple versions of ghc simulataniously. Also cabal expects to find ghc-pkg with a corresponding name to ghc. If you specify `cabal install -w ghc-6.10.1` then it will look for `ghc-6.10.1` on the path and then look for `ghc-pkg-6.10.1` in the same location. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 6 05:39:27 2008 From: trac at galois.com (GHC) Date: Mon Oct 6 05:35:55 2008 Subject: [GHC] #2662: should install ghc-pkg with versioned name again In-Reply-To: <045.4fbb042a5339b9b4bf5b3eb5b9339eb1@localhost> References: <045.4fbb042a5339b9b4bf5b3eb5b9339eb1@localhost> Message-ID: <054.d196f1cc650c0f1b770299f69de2d897@localhost> #2662: should install ghc-pkg with versioned name again --------------------------+------------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 6 05:41:49 2008 From: trac at galois.com (GHC) Date: Mon Oct 6 05:38:19 2008 Subject: [GHC] #1779: unknown symbol `hs_hpc_module' In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost> References: <044.e238a8559ffe0a21198f4a819a87e869@localhost> Message-ID: <053.6ba8f1b3cbf5ecbde8837ee7cff02049@localhost> #1779: unknown symbol `hs_hpc_module' ------------------------------+--------------------------------------------- Reporter: guest | Owner: AndyGill Type: feature request | Status: reopened Priority: low | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: minor | Resolution: Keywords: hpc | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: worksforme => * milestone: 6.10 branch => 6.10.1 Comment: This is happening with 6.10 and HEAD, currently, on the `qq005` test (see log below). Andy - any chance you could look into this? {{{ =====> qq005(hpc) cd ./quasiquotation/qq005 && '/64playpen/simonmar/nightly/HEAD- cam-04-unx/x86_64-unknown-linux/ghc/stage3-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output --make -o qq005 Main -O -fhpc >qq005.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 2] Compiling Expr ( Expr.hs, Expr.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) ghc: ./Expr.o: unknown symbol `hs_hpc_module' Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 6 11:50:25 2008 From: trac at galois.com (GHC) Date: Mon Oct 6 11:46:55 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.8009c41d2d06108dc66ef9cead415171@localhost> #2081: GHC reports internal error: stg_ap_v_ret ------------------------------+--------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Looks odd - timeout is supposed to be built with `-threaded`, but that output doesn't look like it was generated by the threaded RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 6 12:48:58 2008 From: trac at galois.com (GHC) Date: Mon Oct 6 12:45:23 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.c98fb1180c0b6e6d39c19ddcb7120872@localhost> #2081: GHC reports internal error: stg_ap_v_ret ------------------------------+--------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by thorkilnaur): * version: 6.9 => 6.11 Comment: You are right, the {{{+RTS -DSs}}} output was certainly not produced by a {{{timeout}}} compiled with {{{-threaded}}}. If I try that, I get: {{{ $ /Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx- head-2/build/ghc/stage1-inplace/ghc --make timeout.hs -fforce-recomp -O2 -debug -threaded [1 of 1] Compiling Main ( timeout.hs, timeout.o ) Linking timeout ... $ ./timeout 200 'echo Something' +RTS -DSs a0cfe074: allocated 1 capabilities a0cfe074: new task (taskCount: 1) a0cfe074: returning; I want capability 0 a0cfe074: resuming capability 0 a0cfe074: starting new worker on capability 0 a0cfe074: new worker task (taskCount: 2) a0cfe074: task exiting a0cfe074: new task (taskCount: 2) a0cfe074: returning; I want capability 0 f0081000: ### NEW SCHEDULER LOOP (task: 0x600590, cap: 0x2ad30c) f0081000: giving up capability 0 f0081000: passing capability 0 to worker 0xa0cfe074 a0cfe074: resuming capability 0 a0cfe074: created thread 1, stack size = f1 words a0cfe074: new bound thread (1) a0cfe074: ### NEW SCHEDULER LOOP (task: 0x6004d0, cap: 0x2ad30c) a0cfe074: ### Running thread 1 in bound thread a0cfe074: -->> running thread 1 ThreadRunGHC ... a0cfe074: thread 1 did a safe foreign call a0cfe074: freeing capability 0 a0cfe074: thread 1: leaving RTS a0cfe074: returning; I want capability 0 a0cfe074: resuming capability 0 a0cfe074: thread 1: re-entering RTS a0cfe074: created thread 2, stack size = f1 words a0cfe074: --++ thread 1 (ThreadComplete) finished a0cfe074: bound thread (1) finished a0cfe074: passing capability 0 to worker 0xf0081000 a0cfe074: task exiting a0cfe074: new task (taskCount: 2) a0cfe074: returning; I want capability 0 a0cfe074: resuming capability 0 a0cfe074: created thread 3, stack size = f1 words a0cfe074: new bound thread (3) a0cfe074: ### NEW SCHEDULER LOOP (task: 0x6004d0, cap: 0x2ad30c) f0081000: woken up on capability 0 a0cfe074: ### this OS thread cannot run thread 2 f0081000: capability 0 is owned by another task a0cfe074: giving up capability 0 a0cfe074: passing capability 0 to worker 0xf0081000 f0081000: woken up on capability 0 f0081000: resuming capability 0 f0081000: -->> running thread 2 ThreadRunGHC ... f0081000: thread 2 did a safe foreign call f0081000: passing capability 0 to bound task 0xa0cfe074 f0081000: thread 2: leaving RTS a0cfe074: woken up on capability 0 a0cfe074: resuming capability 0 a0cfe074: ### Running thread 3 in bound thread a0cfe074: -->> running thread 3 ThreadRunGHC ... a0cfe074: created thread 4, stack size = f1 words a0cfe074: created thread 5, stack size = f1 words a0cfe074: --<< thread 3 (ThreadRunGHC) stopped: blocked a0cfe074: giving up capability 0 a0cfe074: starting new worker on capability 0 a0cfe074: new worker task (taskCount: 3) f0103000: ### NEW SCHEDULER LOOP (task: 0x6006b0, cap: 0x2ad30c) f0103000: -->> running thread 4 ThreadRunGHC ... f0103000: --<< thread 4 (ThreadRunGHC) stopped: blocked f0103000: -->> running thread 5 ThreadRunGHC ... f0103000: thread 5 did a safe foreign call f0103000: starting new worker on capability 0 f0103000: new worker task (taskCount: 4) f0103000: thread 5: leaving RTS f0103000: forking! f0103000: new task (taskCount: 5) f0185000: ### NEW SCHEDULER LOOP (task: 0x600770, cap: 0x2ad30c) f0185000: giving up capability 0 f0081000: returning; I want capability 0 f0103000: returning; I want capability 0 f0185000: passing capability 0 to worker 0xf0081000 f0081000: resuming capability 0 f0081000: thread 2: re-entering RTS f0081000: --<< thread 2 (ThreadRunGHC) stopped, yielding f0081000: giving up capability 0 f0081000: passing capability 0 to worker 0xf0103000 f0103000: resuming capability 0 f0103000: passing capability 0 to worker 0xf0081000 f0103000: task exiting f0103000: returning; I want capability 0 f0103000: resuming capability 0 f0103000: thread 5: re-entering RTS timeout: internal error: stg_ap_p_ret (GHC version 6.11.20081003 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug f0103000: waking up thread 5 on cap 0 f0103000: raising exception in thread 4. f0103000: raising exception in thread 3. f0103000: raising exception in thread 2. f0103000: discarding task -266842112 f0103000: discarding task -267374592 f0103000: discarding task -267907072 f0103000: discarding task -1596989324 f0103000: created thread 6, stack size = f1 words f0103000: new bound thread (6) f0103000: ### NEW SCHEDULER LOOP (task: 0x600830, cap: 0x2ad30c) f0103000: ### Running thread 6 in bound thread f0103000: -->> running thread 6 ThreadRunGHC ... f0081000: woken up on capability 0 f0081000: capability 0 is owned by another task Something Abort trap $ }}} Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 04:31:47 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 04:28:11 2008 Subject: [GHC] #2663: STM crash with -N2+ Message-ID: <047.219f416ad1bdd20d414e29dc76d8c549@localhost> #2663: STM crash with -N2+ ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The `conc049` and `conc052` tests both crash occasionally when run on multiple processors. I haven't been able to get any useful debugging info yet, they both refuse to crash with `-debug`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 04:55:24 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 04:51:48 2008 Subject: [GHC] #2664: type family + data family + typeclass + type error causes GHC to diverge Message-ID: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> #2664: type family + data family + typeclass + type error causes GHC to diverge ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ {{{ ryani:~ ryani$ ghc-6.11.20081005 -c overflow.hs stack overflow: use +RTS -K to increase it ryani:~ ryani$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 05:20:43 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 05:17:09 2008 Subject: [GHC] #2665: Compiler hangs Message-ID: <044.37dbf6717e2a0a6bac9aacbb809709ca@localhost> #2665: Compiler hangs ---------------------------------+------------------------------------------ Reporter: rolyp | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Sorry for not providing a more specific summary. The following code hangs the 6.8.2 compiler: data U a = U [a] [a] row :: a -> U a row u = U (iterate (fmap id) u) (iterate (fmap id) u) This is the entire program. Simpler versions seem to make the problem go away, although I haven't investigated in detail. I'm running without any special compiler options enabled. I have a suspicion this may be related to the problem with the inliner described at http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs- ghc. cheers, Roly -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 05:25:51 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 05:22:17 2008 Subject: [GHC] #2665: Compiler hangs In-Reply-To: <044.37dbf6717e2a0a6bac9aacbb809709ca@localhost> References: <044.37dbf6717e2a0a6bac9aacbb809709ca@localhost> Message-ID: <053.5372bebdb4b0ba0b1dc00549bcaf5c37@localhost> #2665: Compiler hangs ---------------------------------+------------------------------------------ Reporter: rolyp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by NeilMitchell): It doesn't look like a case of the inliner bug - your data type is not of the right form. Using GHC 6.9 I get the error: {{{ hang.hs:7:20: Couldn't match expected type `a1' against inferred type `f a' `a1' is a rigid type variable bound by the type signature for `row' at hang.hs:6:7 In the first argument of `iterate', namely `(fmap id)' In the first argument of `U', namely `(iterate (fmap id) u)' In the expression: U (iterate (fmap id) u) (iterate (fmap id) u) }}} So your code has a type error, and whatever bug GHC was exhibiting has since been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 09:05:39 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 09:02:01 2008 Subject: [GHC] #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" In-Reply-To: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> References: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> Message-ID: <055.2fa86b90a1924690f8877387d0e137b3@localhost> #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" ----------------------+----------------------------------------------------- Reporter: gwright | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by gwright): * status: closed => reopened * resolution: fixed => Comment: The same program still fails, though differently now on ghc-6.10.0.20080921: {{{ redwing-dakota> ghci-6.10.0.20080921 Vector.hs GHCi, version 6.10.0.20080921: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Data.Vector.Shore.Internal ( Vector.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20080921 for i386-apple-darwin): pushAtom __NULL Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} and ghc-6.10.0.20081006: {{{ redwing-dakota> ghci-6.10.0.20081006 Vector.hs GHCi, version 6.10.0.20081006: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Data.Vector.Shore.Internal ( Vector.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081006 for i386-apple-darwin): pushAtom __NULL Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 09:09:46 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 09:06:19 2008 Subject: [GHC] #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version In-Reply-To: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> References: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> Message-ID: <054.c37a56c6138db8854a3722eb29dff944@localhost> #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Comment (by simonmar): Christian - could you suggest an #ifdef to fix this one? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 09:19:19 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 09:16:02 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.2139eea04ec42cbceb8092275246bda0@localhost> #2081: GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by simonmar): * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 09:19:58 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 09:16:30 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.63296ebfbe9f125a53f6f061144e1daf@localhost> #2337: Data.Array documentation utterly broken ------------------------------+--------------------------------------------- Reporter: japple | Owner: Type: bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 09:21:11 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 09:17:40 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.ddec9e462c78fa06aacf6bd5ada41517@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by simonmar): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 10:30:37 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 10:27:00 2008 Subject: [GHC] #2666: RegAllocLinear error when compling the Crypto-4.1.0 library Message-ID: <045.305db5e802a5cb812eab02d2896d986c@localhost> #2666: RegAllocLinear error when compling the Crypto-4.1.0 library -----------------------+---------------------------------------------------- Reporter: pflynn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- While compiling the Crypto-4.1.0 package with the linux x86 binary package on CentOS5 I received the following error: ghc-6.8.3 : panic! the 'impossible' happened GHC version 6.8.3 for i386-unknown-linux RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph I hope this is not a duplicate but it very well may be. Parnell -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 11:44:31 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 11:40:52 2008 Subject: [GHC] #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" In-Reply-To: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> References: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> Message-ID: <055.ebde1d4518448d44270f1aee15280ae2@localhost> #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" ------------------------------+--------------------------------------------- Reporter: gwright | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * os: MacOS X => Unknown/Multiple * component: Compiler => GHCi * architecture: x86 => Unknown/Multiple * milestone: => 6.10.1 Comment: Happens on Linux/amd64 too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 11:47:19 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 11:43:46 2008 Subject: [GHC] #2665: Compiler hangs In-Reply-To: <044.37dbf6717e2a0a6bac9aacbb809709ca@localhost> References: <044.37dbf6717e2a0a6bac9aacbb809709ca@localhost> Message-ID: <053.c7cf1497d6dc91d8f7062901470fa862@localhost> #2665: Compiler hangs ------------------------------+--------------------------------------------- Reporter: rolyp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Yes, it's a bug in 6.8, fixed in 6.10. Thanks for reporting it though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 7 15:39:28 2008 From: trac at galois.com (GHC) Date: Tue Oct 7 15:35:49 2008 Subject: [GHC] #2667: GHC Linux binary distribution compiler panic bug Message-ID: <045.8e1028c1ccb590aea9f685272d57c4ae@localhost> #2667: GHC Linux binary distribution compiler panic bug -----------------------+---------------------------------------------------- Reporter: pflynn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- When compiling one of my own libraries I received this compiler message: ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-linux): tcIfaceGlobal (local): not found: main:Session.:CoF:R26Dependencies{tc rdk} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 04:49:50 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 04:46:11 2008 Subject: [GHC] #2668: Standalone deriving doesn't do newtype deriving properly Message-ID: <044.57c98c379e66d168145ce5a2a4f71693@localhost> #2668: Standalone deriving doesn't do newtype deriving properly ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ I'd expect the following two declarations to have identical behavior: {{{ newtype S1 x y a = S1 (M S x y a) deriving IxMonad newtype S2 x y a = S2 (M S x y a) deriving instance IxMonad S2 }}} Results: {{{ $ ghc-6.11.20081005 -c deriving.hs deriving.hs:15:0: Can't make a derived instance of `IxMonad S2' (even with cunning newtype deriving: the representation type has wrong kind) In the stand-alone deriving instance for `IxMonad S2' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 07:00:44 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 06:57:05 2008 Subject: [GHC] #2667: GHC Linux binary distribution compiler panic bug In-Reply-To: <045.8e1028c1ccb590aea9f685272d57c4ae@localhost> References: <045.8e1028c1ccb590aea9f685272d57c4ae@localhost> Message-ID: <054.2afdecc17ba31c48dd3b82cb8b0723c3@localhost> #2667: GHC Linux binary distribution compiler panic bug ----------------------+----------------------------------------------------- Reporter: pflynn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > When compiling one of my own libraries I received this compiler message: > > ghc-6.8.3: panic! (the 'impossible' happened) > (GHC version 6.8.3 for i386-unknown-linux): > tcIfaceGlobal (local): not found: > main:Session.:CoF:R26Dependencies{tc rdk} New description: When compiling one of my own libraries I received this compiler message: {{{ ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-linux): tcIfaceGlobal (local): not found: main:Session.:CoF:R26Dependencies{tc rdk} }}} Comment: This almost always means that you have out of date .hi files. We have an open ticket #2648 on making this error message more robust and informative. Can you remove every .hi file and try again? If that fixes it, close the ticket as a duplicate; if not, we'd better investigate further. Thanks very much. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 08:25:53 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 08:22:12 2008 Subject: [GHC] #2663: STM crash with -N2+ In-Reply-To: <047.219f416ad1bdd20d414e29dc76d8c549@localhost> References: <047.219f416ad1bdd20d414e29dc76d8c549@localhost> Message-ID: <056.02df2ef049b19d86df7ab44d3f4f0506@localhost> #2663: STM crash with -N2+ ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge * milestone: 6.10.2 => 6.10.1 Comment: Fixed: {{{ Wed Oct 8 12:26:09 BST 2008 Simon Marlow * Fix #2663: we had a hard-wired capabilities[0] For some unknown reason in schedulePostRunThread() we were always passing capabilities[0] rather than the current Capability to throwToSingleThreaded(). This caused all kinds of weird failures and crashes in STM code when running on multiple processors. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 10:00:40 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 09:57:04 2008 Subject: [GHC] #2669: "index out of range" error message regression Message-ID: <044.80e0e61ca034157992559b1b44b66761@localhost> #2669: "index out of range" error message regression ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ In ghci 6.4.1, we get some useful information with the error: {{{ Prelude> :m +Data.Array.IArray Prelude Data.Array.IArray> (listArray (1,4) [1..4] :: Array Int Int) ! 5 *** Exception: Ix{Int}.index: Index (5) out of range ((1,4)) }}} In ghci 6.8.3, that disappeared: {{{ Prelude> :m +Data.Array.IArray Prelude Data.Array.IArray> (listArray (1,4) [1..4] :: Array Int Int) ! 5 Loading package array-0.1.0.0 ... linking ... done. *** Exception: Error in array index }}} ghci 6.11.20081004 is similarly unhelpful: {{{ Prelude> :m +Data.Array.IArray Prelude Data.Array.IArray> (listArray (1,4) [1..4] :: Array Int Int) ! 5 Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. *** Exception: Error in array index }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 10:17:45 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 10:14:06 2008 Subject: [GHC] #2670: Performance regression Message-ID: <047.05629016d0e3be252c46b232dd152edc@localhost> #2670: Performance regression ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The attached program performs much worse with HEAD as of today (and presumably also 6.10.1) than 6.8.3. {{{ > ghc-6.8.3 --make -O2 bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... > time ./bug 1.17s real 1.17s user 0.01s system 99% ./bug > ghc-6.11 --make -O2 bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... > time ./bug 1.58s real 1.58s user 0.01s system 99% ./bug }}} The problem appears to be in the code for `delete`, GHC has duplicated two calls to `next`. Also note this is a version of the code we have in `eyeball/IOList.lhs` which illustrates some other problems in the current optimiser (although the other problems are not regressions, which is why I'm highlighting this one). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 12:14:40 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 12:10:59 2008 Subject: [GHC] #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 Message-ID: <047.b1877ad5d06e04f09427648c52fc5225@localhost> #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: time | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ $ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> Prelude> :m + System.Locale Data.Time.Clock Data.Time.Format Prelude Data.Time.Format Data.Time.Clock System.Locale> parseTime defaultTimeLocale "%y" "08" :: Ma$ Loading package old-locale-1.0.0.0 ... linking ... done. Loading package time-1.1.2.0 ... linking ... done. Just 1908-01-01 00:00:00 UTC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 12:16:43 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 12:13:04 2008 Subject: [GHC] #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 In-Reply-To: <047.b1877ad5d06e04f09427648c52fc5225@localhost> References: <047.b1877ad5d06e04f09427648c52fc5225@localhost> Message-ID: <056.bb24dbe277e5c5179cd77a5862c639b9@localhost> #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: time | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by simonmic): {{{ $ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 $ ghci Prelude> :m + System.Locale Data.Time.Clock Data.Time.Format Prelude Data.Time.Format Data.Time.Clock System.Locale> parseTime defaultTimeLocale "%y" "08" :: Ma$ Just 1908-01-01 00:00:00 UTC }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 12:18:20 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 12:14:39 2008 Subject: [GHC] #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 In-Reply-To: <047.b1877ad5d06e04f09427648c52fc5225@localhost> References: <047.b1877ad5d06e04f09427648c52fc5225@localhost> Message-ID: <056.0424a88d36cec94777f144a08032ed0d@localhost> #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: time | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by simonmic): Gaah.. one more time {{{ $ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Prelude> :m + System.Locale Data.Time.Clock Data.Time.Format Prelude Data.Time.Format Data.Time.Clock System.Locale> parseTime defaultTimeLocale "%y" "08" :: Maybe UTCTime Just 1908-01-01 00:00:00 UTC }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 16:39:59 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 16:36:19 2008 Subject: [GHC] #2672: Provide GHC Haddock documentation at standard location Message-ID: <047.da2460d8d63644319f154e6a4ee65b5a@localhost> #2672: Provide GHC Haddock documentation at standard location ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: task | Status: new Priority: normal | Component: Documentation Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ GHC's haddock should be put up at a public place, i.e., somewhere under {{{http://haskell.org/ghc/docs/latest/html/}}}. Doing it once per release should be fine, we don't need to automate it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 19:44:19 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 19:40:37 2008 Subject: [GHC] #2668: Standalone deriving doesn't do newtype deriving properly In-Reply-To: <044.57c98c379e66d168145ce5a2a4f71693@localhost> References: <044.57c98c379e66d168145ce5a2a4f71693@localhost> Message-ID: <053.291798854655df5611249b4bff819aa1@localhost> #2668: Standalone deriving doesn't do newtype deriving properly ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by ajd): When I comment out the standalone stuff, GHC gives the message {{{ The equation(s) for 'ret' have one argument, but its type 'M s i i a' has none In the definition for the method 'ret' In the instance declaration for IxMonad (M s) }}} which seems kind of similar... I'm using 6.8.2 on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 8 23:59:12 2008 From: trac at galois.com (GHC) Date: Wed Oct 8 23:55:34 2008 Subject: [GHC] #2661: Associated type synonyms not fully simplified in GHCi In-Reply-To: <045.1a887192f106b18bef3be47f87026bff@localhost> References: <045.1a887192f106b18bef3be47f87026bff@localhost> Message-ID: <054.2229cbba774e8609e1121957f77e72c1@localhost> #2661: Associated type synonyms not fully simplified in GHCi -----------------------+---------------------------------------------------- Reporter: kupopo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: worksforme Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => worksforme Comment: This works for me in GHC 6.10.1 RC 1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 00:54:36 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 00:50:55 2008 Subject: [GHC] #2673: FreeBSD built-in libedit is not compatible with GHC Message-ID: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> #2673: FreeBSD built-in libedit is not compatible with GHC --------------------------+------------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: FreeBSD --------------------------+------------------------------------------------- FreeBSD supplies a version of libedit with the base system, which is installed as /lib/libedit.so.6. It's a different version of the NetBSD code upon which the libedit that ghc uses is built, and it doesn't include any readline support. A version of libedit that works with GHC is in ports, but as it lives in /usr/local/lib and has the same version number as the libedit in /lib, the linker picks up the version in /lib, which causes ghc to fail. The attached patch passes the -rpath flag to the linker, fixing the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 01:32:11 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 01:28:32 2008 Subject: [GHC] #2649: 6.10 regression: panic in tyFamInsts on invalid code In-Reply-To: <047.782af07c34bab674c1b20c9e69317506@localhost> References: <047.782af07c34bab674c1b20c9e69317506@localhost> Message-ID: <056.4e734bb81d9b6e93f3c926f5913d5475@localhost> #2649: 6.10 regression: panic in tyFamInsts on invalid code -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: This bug is already fixed in GHC 6.10.1 RC 1: {{{ TacticalGrace-3 chak 22 (.../Code/haskell): ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.0.20081007 TacticalGrace-3 chak 23 (.../Code/haskell): ghc -c Bug2.hs Bug2.hs:7:12: Pattern signature must exactly match: a In the pattern: _ :: forall a. (Num a) => a In the second argument of `($)', namely `\ (_ :: forall a. (Num a) => a) -> 0' In the expression: g 0 $ \ (_ :: forall a. (Num a) => a) -> 0 }}} The compiler you used must have been pulled from darcs just a few hours before I pushed the patch that fixed it. Nevertheless, the panic points to an infelicity in `Type.tyFamInsts` that may also cause us grief in other situations; so, I'll fix that. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 02:49:48 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 02:46:06 2008 Subject: [GHC] #2672: Provide GHC Haddock documentation at standard location In-Reply-To: <047.da2460d8d63644319f154e6a4ee65b5a@localhost> References: <047.da2460d8d63644319f154e6a4ee65b5a@localhost> Message-ID: <056.4762ad77b630a9b14082ffb768a2a137@localhost> #2672: Provide GHC Haddock documentation at standard location ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by shelarcy): I think you misunderstood the problem. GHC's haddock document is already put at http://www.haskell.org/ghc/dist/stable/docs/libraries/ghc/ and http://www.haskell.org/ghc/dist/current/docs/libraries/ghc/. When GHC 6.10.1 released you can also see GHC's haddock documentation under http://haskell.org/ghc/docs/latest/html/libraries/ghc/ . So, problem is that there is no link to GHC's haddock in parent directories document. See also #2656. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 03:43:02 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 03:39:18 2008 Subject: [GHC] #2674: ghc panic TcPat.checkArgs Message-ID: <047.beba89fbd265d4930e6aee37db6d8846@localhost> #2674: ghc panic TcPat.checkArgs ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ This program using the `derive` package: {{{ {-# LANGUAGE TemplateHaskell, EmptyDataDecls #-} import Data.DeriveTH import Data.Derive.Enum data Void $(derive makeEnum ''Void) }}} produces a compiler panic: {{{ rwbarton@functor:~/code/haskell$ ghc --make panic [1 of 1] Compiling Main ( panic.hs, panic.o ) Loading package base ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package mtl-1.1.0.1 ... linking ... done. Loading package unix-2.3.0.0 ... linking ... done. Loading package process-1.0.0.0 ... linking ... done. Loading package random-1.0.0.0 ... linking ... done. Loading package derive-0.1.1 ... linking ... done. ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): TcPat.checkArgs Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Matt Morrow has reproduced this in a ghc 6.10 prelease. I don't particularly need a derived Enum instance for Void, but the error message told me to report a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 03:56:03 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 03:52:20 2008 Subject: [GHC] #2668: Standalone deriving doesn't do newtype deriving properly In-Reply-To: <044.57c98c379e66d168145ce5a2a4f71693@localhost> References: <044.57c98c379e66d168145ce5a2a4f71693@localhost> Message-ID: <053.aca2c72adc198a1b8528aee9521c24bf@localhost> #2668: Standalone deriving doesn't do newtype deriving properly ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by ryani): Oops, that was just a typo in my test case. Change the instance to declare ret as {{{ ret :: a -> m i i a }}} It compiles fine with the standalone commented out in GHC6.8.3 but gives the same error with it in. I'll upload a fixed attachment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 03:56:34 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 03:52:50 2008 Subject: [GHC] #2666: RegAllocLinear error when compling the Crypto-4.1.0 library In-Reply-To: <045.305db5e802a5cb812eab02d2896d986c@localhost> References: <045.305db5e802a5cb812eab02d2896d986c@localhost> Message-ID: <054.a201f9fed65b4dda3d6c236a42b14bf6@localhost> #2666: RegAllocLinear error when compling the Crypto-4.1.0 library ----------------------+----------------------------------------------------- Reporter: pflynn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: duplicate of #1993 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 05:25:55 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 05:22:18 2008 Subject: [GHC] #2670: Performance regression In-Reply-To: <047.05629016d0e3be252c46b232dd152edc@localhost> References: <047.05629016d0e3be252c46b232dd152edc@localhost> Message-ID: <056.1c6c2089ff99713984a0873c1d6f3924@localhost> #2670: Performance regression ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonpj): Diagnosis first: * Record selector applications are always considered cheap (see `exprIsCheap`) hence duplication of `next`. * It's not clear why CSE doesn't eliminate the nested case. {{{ case (next x) of r { .... (case (next x) or r' { ... } .... } }}} * Why isn't `next` inlined? (In the UNPACK case it actually constructs a pair, so inlining it would eliminate that allocation. Reason: there's an error branch `(error "Cant select next from Nil")`, which has a big static code size. This is silly: the error branch should be floated out, and is in the optimised code for the selector. But record selectors have a built-in unfolding so we don't get the benefit. * Even if we do inline it, all those duplicated error applications are a waste of space. * Perhaps the result-discount thing in `CoreUnfold` should not be discombobulated by the error branch? * We tried writing the record selectors as ordinary functions, and that fixed the problem. More precisely, 6.10 then allocated less heap (by about 10% or so), but strangely was a bit slower in real time. We don't know why. Conclusion: record selectors should probably become ordinary functions. But watch out for consequences for dictionary record selectors. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 05:28:49 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 05:25:06 2008 Subject: [GHC] #2674: ghc panic TcPat.checkArgs In-Reply-To: <047.beba89fbd265d4930e6aee37db6d8846@localhost> References: <047.beba89fbd265d4930e6aee37db6d8846@localhost> Message-ID: <056.40d6d06cfa0b5c05b9045c88540601d5@localhost> #2674: ghc panic TcPat.checkArgs ------------------------------+--------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Thanks. What's happening is this. The parser ensures that a case expression never has zero alternatives, and `checkArgs` assumes this is the case; but Template Haskell makes no such guarantee. The right thing to do is to check for this when converting from TH to `HsSyn`; I've already added some such checks and will add a new one for this case. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 05:59:07 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 05:55:23 2008 Subject: [GHC] #2674: ghc panic TcPat.checkArgs In-Reply-To: <047.beba89fbd265d4930e6aee37db6d8846@localhost> References: <047.beba89fbd265d4930e6aee37db6d8846@localhost> Message-ID: <056.74e332a5e94ba15108e031853893dc10@localhost> #2674: ghc panic TcPat.checkArgs ------------------------------+--------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by rwbarton): A function declaration with no clauses causes the same panic. (Maybe this is handled by the same code.) {{{ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH $(return [FunD (mkName "foo") []]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 05:59:46 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 05:56:03 2008 Subject: [GHC] #2668: Standalone deriving doesn't do newtype deriving properly In-Reply-To: <044.57c98c379e66d168145ce5a2a4f71693@localhost> References: <044.57c98c379e66d168145ce5a2a4f71693@localhost> Message-ID: <053.aa2c5a65b721a6cdfc74cfdae67c1992@localhost> #2668: Standalone deriving doesn't do newtype deriving properly ------------------------------+--------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Excellent report. That's a bug. I'll get to it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 08:11:43 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 08:07:59 2008 Subject: [GHC] #2667: GHC Linux binary distribution compiler panic bug In-Reply-To: <045.8e1028c1ccb590aea9f685272d57c4ae@localhost> References: <045.8e1028c1ccb590aea9f685272d57c4ae@localhost> Message-ID: <054.ec98d5cb92430ada0c83596779e9d63d@localhost> #2667: GHC Linux binary distribution compiler panic bug ----------------------+----------------------------------------------------- Reporter: pflynn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by pflynn): * status: new => closed * resolution: => duplicate Comment: Removing the .hi files fixed it. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 09:32:52 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 09:29:14 2008 Subject: [GHC] #2639: Core lint failure with type families, data families, and typeclasses In-Reply-To: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> References: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> Message-ID: <053.20fbc74e49e0771e1912ca2c50128672@localhost> #2639: Core lint failure with type families, data families, and typeclasses ------------------------------+--------------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2639 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by chak): * testcase: => T2639 * status: new => closed * resolution: => fixed Comment: The type checker completely omitted to produce one cast plus associated coercion when data family pattern matching was combined with local type refinement. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 09:56:18 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 09:52:37 2008 Subject: [GHC] #2639: Core lint failure with type families, data families, and typeclasses In-Reply-To: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> References: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> Message-ID: <053.7b760e4e0de4f83129fef93c66cfe473@localhost> #2639: Core lint failure with type families, data families, and typeclasses ------------------------------+--------------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2639 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by chak): BTW, thanks for all these very concise bug reports. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 10:26:05 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 10:22:22 2008 Subject: [GHC] #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" In-Reply-To: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> References: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> Message-ID: <055.6768a8ea58a35d22bbadc081c1a12583@localhost> #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" ------------------------------+--------------------------------------------- Reporter: gwright | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: => igloo * type: bug => merge Comment: Fixed: {{{ Thu Oct 9 10:11:18 BST 2008 Simon Marlow * pushAtom: add missing case for MachNullAddr (#2589) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 10:51:52 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 10:48:09 2008 Subject: [GHC] #2319: STM not as fair as it could be In-Reply-To: <044.81823a3e2ec18990aac9bedd6527630b@localhost> References: <044.81823a3e2ec18990aac9bedd6527630b@localhost> Message-ID: <053.3e67cc7c60c688a5b79bf1f9993370f5@localhost> #2319: STM not as fair as it could be ------------------------------+--------------------------------------------- Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by josef): I'd really like for this patch to get into 6.10.1. Pretty please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 11:52:51 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 11:50:29 2008 Subject: [GHC] #2675: Malformed pragma causes hang under emacs Message-ID: <048.1e4bef332e235556b6a741635b10a012@localhost> #2675: Malformed pragma causes hang under emacs ----------------------------------------+----------------------------------- Reporter: ezrakilty | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.3 | Severity: normal Keywords: emacs haskell-ghci-mode | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ----------------------------------------+----------------------------------- Running GHCi 6.8.3 under the Emacs haskell-ghci mode, an unterminated pragma causes emacs to hang. Not sure if this is a bug in haskell-ghci mode specifically; running the same file from outside emacs gives an error message, as expected, and doesn't hang. Here's a minimal test case: {{{ {-# LANGUAGE PatternSignatures -} }}} Note the lack of terminating `#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 16:48:30 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 16:44:45 2008 Subject: [GHC] #2676: GHCi 6.10 prints `^[[A' for [UP], `^?' for [BACKSPACE] instead of intended action Message-ID: <046.7210aa1cf4357ce7430c938d4c4820b0@localhost> #2676: GHCi 6.10 prints `^[[A' for [UP], `^?' for [BACKSPACE] instead of intended action -------------------------------+-------------------------------------------- Reporter: dorinho | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: | Severity: normal Keywords: GHCi keymap | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- OS: Xubuntu Hardy 64 bit (no problems with GHCi 6.8.3)[[BR]] Version: GHCi 6.10.0.20081007 (standard configuration)[[BR]] Interpretation: keymapping readline? configure? As example, the output of entering [BACKSPACE][UP] just after starting GHCi: {{{ nick@weg:~> ghci GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> ^?^[[A }}} Thanks for the great work... :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 16:52:20 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 16:48:38 2008 Subject: [GHC] #2676: GHCi 6.10 prints `^[[A' for [UP], `^?' for [BACKSPACE] instead of intended action In-Reply-To: <046.7210aa1cf4357ce7430c938d4c4820b0@localhost> References: <046.7210aa1cf4357ce7430c938d4c4820b0@localhost> Message-ID: <055.7eae14069bcb8b1aa0731e76208dcc7a@localhost> #2676: GHCi 6.10 prints `^[[A' for [UP], `^?' for [BACKSPACE] instead of intended action -------------------------------+-------------------------------------------- Reporter: dorinho | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: Severity: normal | Resolution: duplicate Keywords: GHCi keymap | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by dorinho): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 16:54:59 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 16:51:17 2008 Subject: [GHC] #2676: (->2606) GHCi 6.10 prints `^[[A' for [UP], `^?' for [BACKSPACE] instead of intended action In-Reply-To: <046.7210aa1cf4357ce7430c938d4c4820b0@localhost> References: <046.7210aa1cf4357ce7430c938d4c4820b0@localhost> Message-ID: <055.8ae66c51fd3f892376afee232f6afc3b@localhost> #2676: (->2606) GHCi 6.10 prints `^[[A' for [UP], `^?' for [BACKSPACE] instead of intended action -------------------------------+-------------------------------------------- Reporter: dorinho | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: Severity: normal | Resolution: duplicate Keywords: GHCi keymap | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by dorinho): * summary: GHCi 6.10 prints `^[[A' for [UP], `^?' for [BACKSPACE] instead of intended action => (->2606) GHCi 6.10 prints `^[[A' for [UP], `^?' for [BACKSPACE] instead of intended action Comment: Duplicate of ticket 2606 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 18:10:45 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 18:07:06 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.2c89f9b3a9485be0ef7da504bf4d9be2@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by dorinho): Replying to [comment:6 judah]: > Hmm, if you had to install libedit-dev to build that program then maybe ghc's editline bindings weren't built when you built ghc. Can you please check whether ghc's editline package is installed, for example by: > - trying to run {{{:browse System.Console.Editline.Readline}}} inside ghci > - double-checking whether the up/down arrow keys page through the ghci history > > If it's not installed, you can probably fix this problem by building ghc again. It's also missing in my case, additionally it seems that '''readline''' is the only one of the darcs packages missing at the source distributions (6.10,6.11) - might this problem be nonexistent if building from darcs? What's the reason to omit readline? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 18:14:19 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 18:10:39 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.45405c164d746721ffd383508ff52bd6@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by dorinho): Replying to [comment:8 dorinho]: > Replying to [comment:6 judah]: > > Hmm, if you had to install libedit-dev to build that program then maybe ghc's editline bindings weren't built when you built ghc. Can you please check whether ghc's editline package is installed, for example by: > > - trying to run {{{:browse System.Console.Editline.Readline}}} inside ghci > > - double-checking whether the up/down arrow keys page through the ghci history > > > > If it's not installed, you can probably fix this problem by building ghc again. > > It's also missing in my case, additionally it seems that '''readline''' is the only one of the darcs GHC boot packages missing at the source distributions (6.10,6.11) - might this problem be nonexistent if building from darcs? What's the reason to omit readline? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 19:38:24 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 19:34:40 2008 Subject: [GHC] #2662: should install ghc-pkg with versioned name again In-Reply-To: <045.4fbb042a5339b9b4bf5b3eb5b9339eb1@localhost> References: <045.4fbb042a5339b9b4bf5b3eb5b9339eb1@localhost> Message-ID: <054.a1543f7d00f830d643464486a6eda3e9@localhost> #2662: should install ghc-pkg with versioned name again --------------------------+------------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 19:58:26 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 19:54:42 2008 Subject: [GHC] #2677: Detection of TF instance conflict depends on instance order Message-ID: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> #2677: Detection of TF instance conflict depends on instance order -------------------------------------+-------------------------------------- Reporter: reinerp | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: TF instance conflict | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -------------------------------------+-------------------------------------- With 6.10 RC1, the following code compiles without complaint: {{{ {-# OPTIONS -fglasgow-exts #-} module OverlapTest where type family A x type instance A a = Bool type instance A Int = Char }}} even though the overlapping instances "A a" and "A Int" conflict. Reordering the instances to {{{ {-# OPTIONS -fglasgow-exts #-} module OverlapTest where type family A x type instance A Int = Char type instance A a = Bool }}} correctly doesn't compile, complaining about conflicting instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 9 22:40:55 2008 From: trac at galois.com (GHC) Date: Thu Oct 9 22:37:10 2008 Subject: [GHC] #2678: hLookAhead + hSetBuffering = unsupported operation (Illegal seek) Message-ID: <044.ebc0cd7ca21089d8e742f250c2a46ae6@localhost> #2678: hLookAhead + hSetBuffering = unsupported operation (Illegal seek) ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ If you compile and run this program, and then press 'a' while it is running: {{{ module Main (main) where import System.IO main :: IO () main = do hSetBuffering stdin NoBuffering hLookAhead stdin >>= print hSetBuffering stdin LineBuffering }}} then you get (amd64/Linux): {{{ $ ./y a'a' y: : hSetBuffering: unsupported operation (Illegal seek) }}} The docs at http://www.haskell.org/ghc/docs/latest/html/libraries/base/System- IO.html#v%3AhSetBuffering say what happens when setting a buffer to !NoBuffering, but don't give any clue that this can happen when changing to !LineBuffering. I don't know if it is the behaviour or the docs that should be changed. Also happens in the 6.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 01:28:01 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 01:24:23 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.b93f68353740446c4e0772451c38acf8@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by judah): In 6.10 ghci uses the editline (libedit) package instead of readline, so only the former is distributed by default. The readline package can still be downloaded from hackage.haskell.org if needed. In order to get the rich line-editing interface you need to have the libedit library installed before building ghc; see [wiki:Building/Prerequisites] for more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 03:38:50 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 03:35:06 2008 Subject: [GHC] #2673: FreeBSD built-in libedit is not compatible with GHC In-Reply-To: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> References: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> Message-ID: <057.bd3a89051eb41754e2bee651539c6ada@localhost> #2673: FreeBSD built-in libedit is not compatible with GHC --------------------------+------------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: FreeBSD --------------------------+------------------------------------------------- Comment (by judah): You can pass arguments to the configure script to achieve the same effect. Namely: {{{./configure --with-editline-libraries=/opt/local/lib}}} Please let us know whether this works for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 03:57:05 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 03:53:29 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.7f24327fac406ca8ef07f1c9064fdc87@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by dorinho): Replying to [comment:10 judah]: > In 6.10 ghci uses the editline (libedit) package instead of readline, so only the former is distributed by default. The readline package can still be downloaded from hackage.haskell.org if needed. > > In order to get the rich line-editing interface you need to have the libedit library installed before building ghc; see [wiki:Building/Prerequisites] for more information. :-) Meanwhile, I am using HEAD in darcs (6.11.20081009) and added the libedit-dev package to (x)ubuntu. It seems to work - thank you very much! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 04:23:39 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 04:20:00 2008 Subject: [GHC] #2679: dph build failure on Sparc Solaris 10 for ghc-6.10.0.20081007 Message-ID: <045.1c0db8781eff729304209aa2701e41ba@localhost> #2679: dph build failure on Sparc Solaris 10 for ghc-6.10.0.20081007 -----------------------+---------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: sparc | Os: Solaris -----------------------+---------------------------------------------------- because cpp was not found {{{ gmake -C dph dph-seq gmake[2]: Entering directory `/export/local2/home/maeder/haskell/ghc-6.10.0.20081007/libraries/dph' rm -rf dph-seq rm -rf dph-seq.tmp mkdir dph-seq.tmp cp dph/Setup.hs dph-seq.tmp/ cpp -DUSE_dph_seq < dph/dph.cabal | grep -v "^#" > dph-seq.tmp/dph.cabal /bin/sh: cpp: not found gmake[2]: *** [dph-seq] Error 1 gmake[2]: Leaving directory `/export/local2/home/maeder/haskell/ghc-6.10.0.20081007/libraries/dph' gmake[1]: *** [dph/dph-seq] Error 2 gmake[1]: Leaving directory `/export/local2/home/maeder/haskell/ghc-6.10.0.20081007/libraries' gmake: *** [stage1] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 05:00:56 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 04:57:12 2008 Subject: [GHC] #2679: dph build failure on Sparc Solaris 10 for ghc-6.10.0.20081007 In-Reply-To: <045.1c0db8781eff729304209aa2701e41ba@localhost> References: <045.1c0db8781eff729304209aa2701e41ba@localhost> Message-ID: <054.746a691d2fd272e55c4fe81b59f9412e@localhost> #2679: dph build failure on Sparc Solaris 10 for ghc-6.10.0.20081007 ---------------------------------+------------------------------------------ Reporter: maeder | Owner: rl Type: bug | Status: assigned Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by rl): * status: new => assigned * owner: => rl * version: 6.8.3 => 6.9 * os: Solaris => Unknown/Multiple * architecture: sparc => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 05:01:40 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 04:57:58 2008 Subject: [GHC] #2664: type family + data family + typeclass + type error causes GHC to diverge In-Reply-To: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> References: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> Message-ID: <053.b320029e75599a666c879e5bcd430ad8@localhost> #2664: type family + data family + typeclass + type error causes GHC to diverge ------------------------------+--------------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => chak * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 07:49:00 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 07:45:14 2008 Subject: [GHC] #2678: hLookAhead + hSetBuffering = unsupported operation (Illegal seek) In-Reply-To: <044.ebc0cd7ca21089d8e742f250c2a46ae6@localhost> References: <044.ebc0cd7ca21089d8e742f250c2a46ae6@localhost> Message-ID: <053.4a4b509abbe90151df7dd4e49b18fccf@localhost> #2678: hLookAhead + hSetBuffering = unsupported operation (Illegal seek) ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * milestone: => 6.10.2 Comment: Yes, we could support this. Changing buffering mode is currently done by just flushing the buffer first, which in the case of a ReadMode handle means seeking backwards so we read the same data again, but of course that fails on a non-seekable Handle. But of course it's possible to change to "more buffering" without flushing the current buffer, so we should do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 07:53:19 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 07:49:34 2008 Subject: [GHC] #1779: unknown symbol `hs_hpc_module' In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost> References: <044.e238a8559ffe0a21198f4a819a87e869@localhost> Message-ID: <053.71ac30f06108a7833e221d8ef449f50d@localhost> #1779: unknown symbol `hs_hpc_module' ------------------------------+--------------------------------------------- Reporter: guest | Owner: AndyGill Type: bug | Status: reopened Priority: low | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: minor | Resolution: Keywords: hpc | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 09:16:24 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 09:12:39 2008 Subject: [GHC] #2636: Error message for missing import substantially worse in 6.9/6.11 In-Reply-To: <051.f86bb43b82a519168d8fbe26645dafad@localhost> References: <051.f86bb43b82a519168d8fbe26645dafad@localhost> Message-ID: <060.d3b4e7ec7179e786884c6f9ee894b751@localhost> #2636: Error message for missing import substantially worse in 6.9/6.11 ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 10:20:19 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 10:16:33 2008 Subject: [GHC] #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" In-Reply-To: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> References: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> Message-ID: <055.a9459dc7f4d92d3abb240201f4c2ce96@localhost> #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" ------------------------------+--------------------------------------------- Reporter: gwright | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 10:20:56 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 10:17:13 2008 Subject: [GHC] #2639: Core lint failure with type families, data families, and typeclasses In-Reply-To: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> References: <044.1fe57fcb1a87fc18a01b1efbee2eeb8e@localhost> Message-ID: <053.cee13e72b79aef04aa81deb9790a2860@localhost> #2639: Core lint failure with type families, data families, and typeclasses ------------------------------+--------------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2639 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 10:45:34 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 10:41:46 2008 Subject: [GHC] #2680: Type-checking performance regression Message-ID: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> #2680: Type-checking performance regression ---------------------------------------------+------------------------------ Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------------------+------------------------------ Attached is a module Def1, which defines a load of type synonyms and some values, and a module !ReExport1, which just re-exports Def1. 6.10 is comparable to 6.8 when compiling Def1, but rather than taking a couple of seconds to compile !ReExport1 it takes about 3 minutes. Def2/ReExport2 are the same, but only contain the type synonyms. The difference in this case is 1 second vs 30 seconds. GHC 6.8.2: {{{ $ rm *.o; rm *.hi $ time $GHC -O -fforce-recomp -c Def1.hs $GHC -O -fforce-recomp -c Def1.hs 36.00s user 0.82s system 100% cpu 36.717 total $ time $GHC -O -fforce-recomp -c ReExport1.hs $GHC -O -fforce-recomp -c ReExport1.hs 2.22s user 0.11s system 100% cpu 2.332 total $ time $GHC -O -fforce-recomp -c Def2.hs $GHC -O -fforce-recomp -c Def2.hs 7.20s user 0.14s system 99% cpu 7.340 total $ time $GHC -O -fforce-recomp -c ReExport2.hs $GHC -O -fforce-recomp -c ReExport2.hs 0.99s user 0.08s system 100% cpu 1.075 total $ $GHC --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 }}} 6.10 branch: {{{ $ rm *.o; rm *.hi $ time $GHC -O -fforce-recomp -c Def1.hs $GHC -O -fforce-recomp -c Def1.hs 35.94s user 0.60s system 100% cpu 36.350 total $ time $GHC -O -fforce-recomp -c ReExport1.hs $GHC -O -fforce-recomp -c ReExport1.hs 169.35s user 0.28s system 99% cpu 2:49.67 total $ time $GHC -O -fforce-recomp -c Def2.hs $GHC -O -fforce-recomp -c Def2.hs 8.37s user 0.11s system 100% cpu 8.477 total $ time $GHC -O -fforce-recomp -c ReExport2.hs $GHC -O -fforce-recomp -c ReExport2.hs 29.11s user 0.10s system 99% cpu 29.258 total $ $GHC --version The Glorious Glasgow Haskell Compilation System, version 6.10.0.20081009 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 10:46:06 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 10:42:18 2008 Subject: [GHC] #2680: Type-checking performance regression In-Reply-To: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> References: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> Message-ID: <053.ff7d61638354cc1628690b45f5dc7ad7@localhost> #2680: Type-checking performance regression ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Comment (by igloo): This is a cutdown version of type-level-0.2.2 from hackage, incidentally. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 10:49:27 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 10:45:41 2008 Subject: [GHC] #2681: Incorrect imported module not used warning Message-ID: <051.f2101c9b0af44159aa830a401dfe3aaf@localhost> #2681: Incorrect imported module not used warning ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ A test case, with 3 files in. {{{ -- AAA.hs module AAA where data Foo = Foo -- AA.hs module AA(Foo) where import AAA -- A.hs module A where import qualified AA import AAA type Bar = AA.Foo }}} Trying it out gives: {{{ $ ghc --make [3 of 3] Compiling A ( A.hs, A.o ) A.hs:2:0: Warning: Module `AA' is imported, but nothing from it is used, except perhaps instances visible in `AA' To suppress this warning, use: import AA() }}} {{{Foo}}} comes from {{{AAA}}}, but is used with the import from {{{AA}}}, so it should be saying {{{AAA} is imported but not used. It seems the import warnings are based on final fully resolved names, but this doesn't deal with re-exports or qualification correctly. I came accross this test case while tracking down a much more complex example which gave a case where an unqualified module was reported as being redundant - despite the fact that it was required - so it seems there are several bugs around this area. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 11:00:04 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 10:56:18 2008 Subject: [GHC] #2267: Bogus "unused import" warning In-Reply-To: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> References: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> Message-ID: <055.e8dedbf14f60ca6710be6ec4ed4c3300@localhost> #2267: Bogus "unused import" warning ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: 6.10 branch => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 11:02:27 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 10:58:42 2008 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.a6c7315d0b9d9557a80516414e900acf@localhost> #1074: -fwarn-unused-imports complains about wrong import ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: _|_ => 6.10.2 Comment: This is biting more and more people, as warnings are increasingly enabled by users. Also, it's a real pain to workaround. Let's just rewrite the warning code and fix it. See also #2681, #1148, #2267. (nb. my algorithm above needs extending to work with qualified imports too) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 11:03:37 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 10:59:51 2008 Subject: [GHC] #2681: Incorrect imported module not used warning In-Reply-To: <051.f2101c9b0af44159aa830a401dfe3aaf@localhost> References: <051.f2101c9b0af44159aa830a401dfe3aaf@localhost> Message-ID: <060.bbfb723df2e292066a9d0cf18ae05452@localhost> #2681: Incorrect imported module not used warning ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. We already have a ticket for this: #1074. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 11:06:14 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 11:02:27 2008 Subject: [GHC] #2680: Type-checking performance regression In-Reply-To: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> References: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> Message-ID: <053.518e83daddedc0bed096cc273c760a11@localhost> #2680: Type-checking performance regression ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Comment (by simonpj): That's very mysterious -- and highly terrible. When compiling `ReExport1.hs` I get past tidy-core very fast, and then it gets totally stuck. Do you have a profiled compiler to see what it's up to? My guess is that there's a very non-linear algorithm in the interface file generation. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 11:06:12 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 11:02:41 2008 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.e6eba4d11f0530e37e34bf9cf4bac509@localhost> #1074: -fwarn-unused-imports complains about wrong import ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by NeilMitchell): * cc: neil.mitchell.2@credit-suisse.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 11:07:55 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 11:04:09 2008 Subject: [GHC] #2636: Error message for missing import substantially worse in 6.9/6.11 In-Reply-To: <051.f86bb43b82a519168d8fbe26645dafad@localhost> References: <051.f86bb43b82a519168d8fbe26645dafad@localhost> Message-ID: <060.91e35abc2dc8bf615140f4245053dbea@localhost> #2636: Error message for missing import substantially worse in 6.9/6.11 ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Fri Oct 10 14:15:35 BST 2008 Simon Marlow * fix #2636: throw missing module errors as SourceErrors, not ErrMsg }}} which also needs an update to Haddock, as I removed `ErrUtils.handleErrMsg`: {{{ Fri Oct 10 15:43:04 BST 2008 Simon Marlow * no need for handleErrMsg now, we don't throw any ErrMsgs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 11:08:41 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 11:04:55 2008 Subject: [GHC] #2319: STM not as fair as it could be In-Reply-To: <044.81823a3e2ec18990aac9bedd6527630b@localhost> References: <044.81823a3e2ec18990aac9bedd6527630b@localhost> Message-ID: <053.3db2970c933ac76fc8e9942bb62003b7@localhost> #2319: STM not as fair as it could be ------------------------------+--------------------------------------------- Reporter: josef | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge * milestone: 6.10 branch => 6.10.1 Comment: tested and pushed. {{{ Fri Oct 10 16:03:22 BST 2008 Josef Svenningsson * When waking up thread blocked on TVars, wake oldest first (#2319) StgTVarWatchQueue contains the threads blocked on a TVar in order youngest first. The list has to be traversed backwards to unpark the threads oldest first. This improves the fairness when using STM in some situations. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 12:02:03 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 11:58:21 2008 Subject: [GHC] #2673: FreeBSD built-in libedit is not compatible with GHC In-Reply-To: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> References: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> Message-ID: <057.f14ead07fc9d01242e18accc4937acbd@localhost> #2673: FreeBSD built-in libedit is not compatible with GHC --------------------------+------------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: FreeBSD --------------------------+------------------------------------------------- Comment (by gmainland): Yes, I already do that. The problem is that the run-time linker looks for libedit in /lib before /usr/local/lib, so I had to use -rpath to force it to look in /usr/local/lib. I guess the -L flag I added in the patch may be unnecessary, but the -Wl,-rpath definitely is needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 13:17:05 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 13:13:17 2008 Subject: [GHC] #2680: Type-checking performance regression In-Reply-To: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> References: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> Message-ID: <053.e4faa02b1598f663df4959c6e61703e3@localhost> #2680: Type-checking performance regression ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Comment (by duncan): A possibly releated real test case is the Vec library from hackage. We noticed that takes a long time to build which we didn't notice with 6.8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Vec Another one that is much much slowe to compile with 6.10 vs 6.8 is WURFL. However that looks more likely to be a parser issue than typechecking. It's got large amounts of generated code. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/WURFL -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 15:29:38 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 15:25:53 2008 Subject: [GHC] #311: gmp's memory management In-Reply-To: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> References: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> Message-ID: <052.865d3685634bc2f6abb7a16a7aa9715b@localhost> #311: gmp's memory management ------------------------------+--------------------------------------------- Reporter: as49 | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (FFI) | Version: 6.4 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by judahj): In the following post, Ale? Bizjak suggests the following workaround: use the foreign library's custom memory interface, and allocate with malloc. http://www.haskell.org/pipermail/haskell-cafe/2008-October/048812.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 15:47:04 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 15:43:16 2008 Subject: [GHC] #2680: Type-checking performance regression In-Reply-To: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> References: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> Message-ID: <053.f72cc7ee88aef5892825e829ed9f403c@localhost> #2680: Type-checking performance regression ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Comment (by igloo): The problem is in the creation of `ent_map` in `iface/MkIface:mk_usage_info`. In this case, all of the `mod`s are the same, so `extendModuleEnv_C (++) mv_map mod [occ]` builds the list of them quadratically. Using `(flip (++))` brings the time down to a couple of seconds. It doesn't look to me like the order of elements should be important here, but can you confirm please? {{{ hunk ./compiler/iface/MkIface.lhs 821 - Just mod -> extendModuleEnv_C (++) mv_map mod [occ] + Just mod -> extendModuleEnv_C (flip (++)) mv_map mod [occ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 17:44:26 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 17:40:39 2008 Subject: [GHC] #2680: Type-checking performance regression In-Reply-To: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> References: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> Message-ID: <053.fa1e8ffec05215f3f5cbe6a6590ff16a@localhost> #2680: Type-checking performance regression ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Comment (by igloo): Vec isn't the same problem. There's a twisty maze of fundeps and undecidable instances is on; I'm not sure if the problem is in the code or GHC. If anyone wants to look, the `Det'` instance starting on line 371 of `Data/Vec/LinAlg.hs` seems to be the (or at least, a) cause of non- termination. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 18:00:26 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 17:56:42 2008 Subject: [GHC] #2682: Keep going after failed search for module in current directory Message-ID: <042.3ab3a08a92cd2130db77f37efdac62b0@localhost> #2682: Keep going after failed search for module in current directory ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Inside a package's source directory after the package has been installed, if I type {{{ghci}}} and then {{{import MODNAME}}}, where MODNAME is a module in the package, GHCi throws an error: {{{module main:MODNAME is not loaded}}}, even though MODNAME is part of the package (in its system- installed state). The desired behavior, I think, is to keep on going and realize that MODNAME is a module in an already-installed package, and then load that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 19:47:10 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 19:43:22 2008 Subject: [GHC] #2680: Type-checking performance regression In-Reply-To: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> References: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> Message-ID: <053.4aa1eb40511d818f7e0ca03fca3fb4c1@localhost> #2680: Type-checking performance regression ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Comment (by igloo): WURFL looks like a non-regression to me. I get a stack overflow with 6.8 and 6.10 when compiling with optimisation, and they both compile in ~40 seconds with optimisation off. The problem is a huge datastructure, which we have other tickets for. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 10 23:52:31 2008 From: trac at galois.com (GHC) Date: Fri Oct 10 23:48:41 2008 Subject: [GHC] #2683: Regression with 6.10: panic in xmonad-contrib Message-ID: <043.cf6c9356908d84d15cb72785d970ada9@localhost> #2683: Regression with 6.10: panic in xmonad-contrib -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: critical Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Testing xmonad-contrib-0.8 with ghc 6.10 RC. Probably a release-blocking bug. {{{ [ 35 of 138] Compiling XMonad.Layout.MultiToggle ( XMonad/Layout/MultiToggle.hs, dist/build/XMonad/Layout/MultiToggle.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for x86_64-unknown-linux): ASSERT failed! file typecheck/TcUnify.lhs line 1000 a{tv aKF8} [box] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} To reproduced, grab cabal-install 0.6 and: {{{ cabal install xmonad-contrib-0.8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 11 02:59:11 2008 From: trac at galois.com (GHC) Date: Sat Oct 11 02:55:22 2008 Subject: [GHC] #2684: Stack overflow in stream-fusion library with GHC 6.10 RC Message-ID: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> #2684: Stack overflow in stream-fusion library with GHC 6.10 RC ---------------------------------+------------------------------------------ Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: major Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Regression from GHC 6.8.x to GHC 6.10 release candidate, {{{ $ runhaskell Setup.lhs configure Configuring stream-fusion-0.1.1... $ runhaskell Setup.lhs build Preprocessing library stream-fusion-0.1.1... Building stream-fusion-0.1.1... ... Data/Stream.hs:575:4: Warning: Pattern match(es) are non-exhaustive In the definition of `next': Patterns not matched: (_ :!: (Just (L _))) :!: S2 [2 of 3] Compiling Data.List.Stream ( Data/List/Stream.hs, dist/build/Data/List/Stream.o ) stack overflow: use +RTS -K to increase it }}} The stack overflow was not present with GHC 6.8.x You can get the code here: http://hackage.haskell.org/cgi-bin/hackage- scripts/package/stream-fusion -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 11 08:01:50 2008 From: trac at galois.com (GHC) Date: Sat Oct 11 07:58:05 2008 Subject: [GHC] #2683: Regression with 6.10: panic in xmonad-contrib In-Reply-To: <043.cf6c9356908d84d15cb72785d970ada9@localhost> References: <043.cf6c9356908d84d15cb72785d970ada9@localhost> Message-ID: <052.5c33d475990cf0fcb84525a74661ae7c@localhost> #2683: Regression with 6.10: panic in xmonad-contrib ----------------------+----------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 Comment: You need a DEBUG compiler to reproduce this (so it may not be a regression, but we should take a look anyway): {{{ {-# LANGUAGE ExistentialQuantification, MultiParamTypeClasses, FunctionalDependencies, Rank2Types #-} module Q where class Transformer t a | t -> a where transform :: t -> l a -> (forall l'. l' a -> b) -> b data EL a = forall l. EL (l a) unEL :: EL a -> (forall l. l a -> b) -> b unEL = undefined transform' :: (Transformer t a) => t -> EL a -> EL a transform' = undefined data MultiToggleS ts a = MultiToggleS ts data MultiToggle = MultiToggle expand :: HList ts a => MultiToggleS ts a -> MultiToggle expand (MultiToggleS ts) = resolve ts (\x mt -> let g = transform' x in mt ) MultiToggle class HList c a where resolve :: c -> (forall t. (Transformer t a) => t -> b) -> b }}} {{{ $ ghc -fforce-recomp -c q.hs ghc: panic! (the 'impossible' happened) (GHC version 6.11.20081010 for x86_64-unknown-linux): ASSERT failed! file typecheck/TcUnify.lhs line 1000 a{tv ahb} [box] }}} Line 1000 is the second ASSERT here: {{{ unifyType :: TcTauType -> TcTauType -> TcM CoercionI -- No boxes expected inside these types -- Acutal and expected types unifyType ty1 ty2 -- ty1 expected, ty2 inferred = ASSERT2( not (isBoxyTy ty1), ppr ty1 ) ASSERT2( not (isBoxyTy ty2), ppr ty2 ) addErrCtxtM (unifyCtxt ty1 ty2) $ uTysOuter True ty1 True ty2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 11 19:04:10 2008 From: trac at galois.com (GHC) Date: Sat Oct 11 19:00:19 2008 Subject: [GHC] #2684: Stack overflow in stream-fusion library with GHC 6.10 RC In-Reply-To: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> References: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> Message-ID: <052.7b6230447a676b4b4f4f6c198b84eeeb@localhost> #2684: Stack overflow in stream-fusion library with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 Comment: I haven't tracked down exactly what's going on here, but it seems to be going round some sort of loop in functions like `simplNonRecE` and `simplLam`, with binders `[ds_dC6, ds_dC7]` and body {{{ case ds_dC7 of _ { [] -> GHC.Types.[] @ b; : x [ALWAYS Once Nothing] xs [ALWAYS Once Nothing] -> GHC.Types.: @ b (ds_dC6 x) (Data.List.Stream.mapx @ a @ b ds_dC6 xs) }}} I'll attach a cut-down example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 11 19:06:02 2008 From: trac at galois.com (GHC) Date: Sat Oct 11 19:02:13 2008 Subject: [GHC] #2684: Stack overflow in stream-fusion library with GHC 6.10 RC In-Reply-To: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> References: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> Message-ID: <052.c3343c9337016868054a78c13d8a5323@localhost> #2684: Stack overflow in stream-fusion library with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by igloo): Compile with: {{{ ghc --make -O -Wall -XBangPatterns -XExistentialQuantification -XMagicHash -XTypeOperators Data.Stream Data.List.Stream -fforce-recomp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 11 19:18:10 2008 From: trac at galois.com (GHC) Date: Sat Oct 11 19:14:21 2008 Subject: [GHC] #2673: FreeBSD built-in libedit is not compatible with GHC In-Reply-To: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> References: <048.a7a8b8cd246f16f4f13f2f8936382c3e@localhost> Message-ID: <057.bc412d492fe9c675e57488439b62aeaf@localhost> #2673: FreeBSD built-in libedit is not compatible with GHC -----------------------+---------------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: FreeBSD | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: I'm not sure what's the right thing to do here, but hard-coding this particular path seems wrong to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Sun Oct 12 01:36:06 2008 From: conal at conal.net (Conal Elliott) Date: Sun Oct 12 01:32:13 2008 Subject: TypeCompose Patch In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D766E2F95@EA-EXMSG-C334.europe.corp.microsoft.com> References: <5154.24.69.170.39.1222276110.squirrel@squishy.internetofdeath.com> <5614.24.69.170.39.1222291451.squirrel@squishy.internetofdeath.com> <6268.24.69.170.39.1222292558.squirrel@squishy.internetofdeath.com> <20080925005001.GC18545@gmx.de> <638ABD0A29C8884A91BC5FB5C349B1C32D766E2F95@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: What's the status of this bug? I'd like to know when it's safe to upgrade to a new ghc. Also, I want to blog about my linear map implementation, but not when it tickles a ghc bug for me and for readers. Thanks, - Conal 2008/9/25 Simon Peyton-Jones > Conal, Marc > > This is definitely a bug in the new equality-solving mechanism. I can > reproduce it readily. I'll discuss it with Manuel tomorrow and get back to > you. Thanks for finding it! > > Simon > > | -----Original Message----- > | From: glasgow-haskell-bugs-bounces@haskell.org [mailto: > glasgow-haskell-bugs- > | bounces@haskell.org] On Behalf Of Marc Weber > | Sent: 25 September 2008 01:50 > | To: glasgow-haskell-bugs@haskell.org > | Subject: Re: TypeCompose Patch > | > | On Wed, Sep 24, 2008 at 02:55:01PM -0700, Conal Elliott wrote: > | > Eep! That code (which uses type classes) fails to compile under > 6.8.3 > | but > | > does compile under 6.9. Looks like 6.10 broke something. > | > > | > Can anyone else check whether vector-space build or breaks under > 6.10? > | > The repo is > | > > | > [1]http://code.haskell.org/vector-space/ > | > | src/Data/LinearMap.hs|37 col 21 error| > | || Couldn't match expected type `t' against inferred type `Basis u' > | || In the second argument of `(.)', namely `basisValue' > | || In the first argument of `trie', namely `(f . basisValue)' > | || In the expression: trie (f . basisValue) > | > | Hi Conal, I'm getting the error above (current ghc from darcs) > | If you want I can give you an ssh account where this ghc version is > | installed within the next days. > | > | I also had to add a -fglasgow-exts to a MemoTrie file.. > | (Not sure which is the correct language extension which was missing) > | > | Sincerly > | Marc Weber > | _______________________________________________ > | Glasgow-haskell-bugs mailing list > | Glasgow-haskell-bugs@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20081011/0adad9a8/attachment.htm From trac at galois.com Sun Oct 12 06:29:23 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 06:25:33 2008 Subject: [GHC] #2687: Lexical error when compiling unicode-prelude-0.1 using GHC 6.10.1 RC1 Message-ID: <049.bc4576b09ee6219e664f054b11cec9bf@localhost> #2687: Lexical error when compiling unicode-prelude-0.1 using GHC 6.10.1 RC1 ---------------------------------+------------------------------------------ Reporter: albertfong | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Windows ---------------------------------+------------------------------------------ When compiling unicode-prelude-0.1 using GHC 6.10.0.20081007, the following error occurs: {{{ PS X:\unicode-prelude-0.1> runghc Setup.hs build Preprocessing library unicode-prelude-0.1... Building unicode-prelude-0.1... Prelude\Unicode.hs:68:7: lexical error at character '\183' }}} Lexing fails for the 'middle dot' character (\183). This is a regression, since unicode-prelude-0.1 builds successfully with GHC 6.8.3. Link to package [http://hackage.haskell.org/packages/archive/unicode- prelude/0.1/unicode-prelude-0.1.tar.gz here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 06:31:25 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 06:27:38 2008 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.a48154b61e452d89f54d2e4e6a4dac4d@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ----------------------+----------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) Comment: I do often use x{...} as a single term without brackets, but if I couldn't that wouldn't be too much of as hassle. Given that printing should produce unambiguous terms (both for the compiler and the human reader), adding the brackets seems a sensible choice. I am strongly in favour of Hugs and GHC agreeing on this, and indeed on everything. As soon as they don't, we're going to be in the situation where peoples programs behave differently, where test cases need two sets of "matching output" etc. As a regular user of both systems, the current compatibility is wonderful, but perfect compatibility (for a subset of Haskell) would be better. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 07:15:45 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 07:11:53 2008 Subject: [GHC] #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint Message-ID: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint -----------------------------+---------------------------------------------- Reporter: PVerswyvelen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------------+---------------------------------------------- The following code hangs GHC 6.10.0.20081007 on Windows {-# OPTIONS_GHC -XFunctionalDependencies -XMultiParamTypeClasses #-} class VectorSpace v s | v -> s where (*^) :: s -> v -> v (^/) :: v -> s -> v v ^/ s = v *^ (1/s) it should give an error instead (1/s implies a constraint on s which I did not give) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 07:16:49 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 07:12:55 2008 Subject: [GHC] #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint In-Reply-To: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> References: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> Message-ID: <060.e6cbda3695093c1a033c5e2a93bb00dc@localhost> #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint -----------------------------+---------------------------------------------- Reporter: PVerswyvelen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------------+---------------------------------------------- Comment (by PVerswyvelen): Oops, the code should be {{{ class VectorSpace v s | v -> s where (*^) :: s -> v -> v (^/) :: v -> s -> v v ^/ s = v *^ (1/s) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 08:48:47 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 08:44:56 2008 Subject: [GHC] #2687: Lexical error when compiling unicode-prelude-0.1 using GHC 6.10.1 RC1 In-Reply-To: <049.bc4576b09ee6219e664f054b11cec9bf@localhost> References: <049.bc4576b09ee6219e664f054b11cec9bf@localhost> Message-ID: <058.3e7377612401985a265f88d162d45108@localhost> #2687: Lexical error when compiling unicode-prelude-0.1 using GHC 6.10.1 RC1 ------------------------+--------------------------------------------------- Reporter: albertfong | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ------------------------+--------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 Comment: Hmm, this is: {{{ U+00B7 MIDDLE DOT Unicode category: Punctuation, Other }}} which is the same category as !, %, *, etc. The report says {{{ uniSymbol -> any Unicode symbol or punctuation }}} Currently the lexer thinks that {{{ UppercaseLetter -> upper LowercaseLetter -> lower TitlecaseLetter -> upper ModifierLetter -> other_graphic OtherLetter -> lower -- see #1103 NonSpacingMark -> other_graphic SpacingCombiningMark -> other_graphic EnclosingMark -> other_graphic DecimalNumber -> digit LetterNumber -> other_graphic OtherNumber -> other_graphic ConnectorPunctuation -> other_graphic DashPunctuation -> other_graphic OpenPunctuation -> other_graphic ClosePunctuation -> other_graphic InitialQuote -> other_graphic FinalQuote -> other_graphic OtherPunctuation -> other_graphic MathSymbol -> symbol CurrencySymbol -> symbol ModifierSymbol -> symbol OtherSymbol -> symbol Space -> space _ -> non_graphic }}} so at least some of the punctuation characters should be symbol rather than graphic. Should they all be? H98 does say so, although I'm not sure if it intended to include open and closing punctuation (which I assume means various shapes of brackets). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 10:05:25 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 10:01:32 2008 Subject: [GHC] #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint In-Reply-To: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> References: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> Message-ID: <060.ae4bceca47b942ce71016a458e9a8467@localhost> #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint --------------------------+------------------------------------------------- Reporter: PVerswyvelen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > The following code hangs GHC 6.10.0.20081007 on Windows > > {-# OPTIONS_GHC -XFunctionalDependencies -XMultiParamTypeClasses #-} > > class VectorSpace v s | v -> s where > (*^) :: s -> v -> v > (^/) :: v -> s -> v > v ^/ s = v *^ (1/s) > > it should give an error instead (1/s implies a constraint on s which I > did not give) New description: The following code hangs GHC 6.10.0.20081007 on Windows {{{ {-# OPTIONS_GHC -XFunctionalDependencies -XMultiParamTypeClasses #-} class VectorSpace v s | v -> s where (*^) :: s -> v -> v (^/) :: v -> s -> v v ^/ s = v *^ (1/s) }}} it should give an error instead (1/s implies a constraint on s which I did not give) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 10:45:35 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 10:41:41 2008 Subject: [GHC] #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint In-Reply-To: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> References: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> Message-ID: <060.fffd2b80185e7f29a23a7cbda20d7b4b@localhost> #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint ------------------------------+--------------------------------------------- Reporter: PVerswyvelen | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * version: => 6.11 * os: Windows => Unknown/Multiple * architecture: x86 => Unknown/Multiple * milestone: => 6.10.1 Comment: Thanks for the report. It's going round in a loop in typecheck/TcSimplify:checkLoop, where wanteds goes, e.g.: {{{ [$dVectorSpace{amu} :: {Main.VectorSpace v v}, $dFractional{amv} :: {GHC.Real.Fractional v}, $dNum{amw} :: {GHC.Num.Num v}, Wanted t_aoM :: s ~ v, Wanted t_aoS :: v ~ s] }}} then (reordered and new t_*): {{{ [$dNum{amw} :: {GHC.Num.Num v}, $dFractional{amv} :: {GHC.Real.Fractional v}, $dVectorSpace{amu} :: {Main.VectorSpace v v}, Wanted t_aoU :: s ~ v, Wanted t_ap0 :: v ~ s] }}} and then (back to original order and new t_*): {{{ [$dVectorSpace{amu} :: {Main.VectorSpace v v}, $dFractional{amv} :: {GHC.Real.Fractional v}, $dNum{amw} :: {GHC.Num.Num v}, Wanted t_ap2 :: s ~ v, Wanted t_ap8 :: v ~ s] }}} and so on. reduceContext gives an improved hint of: {{{ improved = True [EXTRA EQS] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 10:58:58 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 10:55:04 2008 Subject: [GHC] #2689: make maintainer-clean leaves generated files and directories Message-ID: <044.d82e9d076aeb3a76dac009bdaa86249d@localhost> #2689: make maintainer-clean leaves generated files and directories ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Before updating my GHC head repo, I did `make maintainer-clean`. Recalling some recent bugs triggered by left-over files, I thought I'd try and look for them in advance, and found rather a lot of them. For the purpose, I've got an alternative boringfile (attached) that just hides subrepos and stuff I don't suspect at the moment. {{{ $ make maintainer-clean $ cp .darcs-boring .darcs-boring.safe $ cp .darcs-subrepos .darcs-boring $ darcs cha --last=1 Sat Oct 4 18:53:51 GMT Daylight Time 2008 Ian Lynagh * prep-bin-dist-mingw complains if it finds a bad version of windres $ darcs wh -s M ./.darcs-boring -211 +18 M ./darcs-all -2 +68 $ darcs wh -l >mystuff/leftovers.log -- output attached $ cp .darcs-boring.safe .darcs-boring }}} Perhaps this could be made into an automated test, so that leftovers don't keep piling up until someone trips over them (though you probably don't want the buildbots to clean their results away, in case you need to inspect them later)? See also the related ticket on `make distclean`, #1693. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 11:36:53 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 11:32:59 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.720530fd1d54eca5ae72dff643fae1d1@localhost> #2497: Weird scoping for tyvars in rules --------------------------------------------+------------------------------- Reporter: rl | Owner: Type: bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2497 | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by igloo): * priority: normal => high * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 11:38:58 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 11:35:04 2008 Subject: [GHC] #2563: With -N4: "internal error: RELEASE_LOCK: I do not own this lock: Task.c 269" In-Reply-To: <044.a34da6c43bb4e28144648cb6864c37dc@localhost> References: <044.a34da6c43bb4e28144648cb6864c37dc@localhost> Message-ID: <053.fec1e1164bb1bce8f80d2a7c9c2a7bf1@localhost> #2563: With -N4: "internal error: RELEASE_LOCK: I do not own this lock: Task.c 269" ----------------------+----------------------------------------------------- Reporter: TomMD | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 11:49:45 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 11:45:59 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.c74b9e8846b8db84f194b678d3afca63@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD --------------------+------------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Looks to me like this turned out to be behaving as expected, then. Thanks for tracking it down, guys! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:09:35 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:05:41 2008 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.8087d0f781e9d21dd121ac30f018c4b5@localhost> #2615: ghci doesn't play nice with linker scripts --------------------------+------------------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: This is a long-standing bug, but I can't find a ticket for it. Anyway, we should fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:17:23 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:13:30 2008 Subject: [GHC] #2624: GHC 10.1 beta build error In-Reply-To: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> References: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> Message-ID: <056.c0db4d60b65517038e98e98f84cf8ec4@localhost> #2624: GHC 10.1 beta build error ----------------------+----------------------------------------------------- Reporter: humasect | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > installPackage: internal error: stg_ap_ppp_ret > (GHC version 6.8.3 for i386_apple_darwin) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > make[2]: *** [build.stage.1] Abort trap > make[1]: *** [build.stage.1] Error 2 > make: *** [stage1] Error 1 > > When building ghc-6.10.0.20080921 New description: {{{ installPackage: internal error: stg_ap_ppp_ret (GHC version 6.8.3 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[2]: *** [build.stage.1] Abort trap make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 When building ghc-6.10.0.20080921 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:18:34 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:14:41 2008 Subject: [GHC] #2624: GHC 10.1 beta build error In-Reply-To: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> References: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> Message-ID: <056.1364ff17fae0484cce773d4ba2846bcd@localhost> #2624: GHC 10.1 beta build error ----------------------+----------------------------------------------------- Reporter: humasect | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: As discussed by e-mail, I think, this is actually a bug in 6.8.3. If you also see it with 6.10.1 then please re-open the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:18:43 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:15:07 2008 Subject: [GHC] #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <050.f409c69b6469259efa640144979533d8@localhost> References: <050.f409c69b6469259efa640144979533d8@localhost> Message-ID: <059.465e8259dcbefbd3f232f4d79cb0b5d1@localhost> #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith ------------------------------+--------------------------------------------- Reporter: Bart Massey | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:23:25 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:19:31 2008 Subject: [GHC] #2640: Treat -X flags consistently in GHCi In-Reply-To: <046.b2636e2b36f002a0dd024f2921ea27a7@localhost> References: <046.b2636e2b36f002a0dd024f2921ea27a7@localhost> Message-ID: <055.82fee99857973f4cd7ce24cf1e1335c3@localhost> #2640: Treat -X flags consistently in GHCi ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:31:55 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:28:04 2008 Subject: [GHC] #2641: Make -XExtendedDeafultRules a bit less liberal In-Reply-To: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> References: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> Message-ID: <055.66335028741d5c56299ff976fc15bd18@localhost> #2641: Make -XExtendedDeafultRules a bit less liberal ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch Comment: A couple of thoughts: `-Wall` would warn about the defaulting. Perhaps in GHCi we could have a quieter warning on by default, so instead of either {{{ :1:35: Warning: Defaulting the following constraint(s) to type `()' `Eq a' arising from a use of `==' at :1:35-50 `Test.QuickCheck.Arbitrary a' arising from a use of `Test.QuickCheck.quickCheck' at :1:0-51 `Show a' arising from a use of `Test.QuickCheck.quickCheck' at :1:0-51 In the expression: reverse xs == xs In the first argument of `Test.QuickCheck.quickCheck', namely `(\ xs -> reverse xs == xs)' In a stmt of a 'do' expression: it <- Test.QuickCheck.quickCheck (\ xs -> reverse xs == xs) }}} or nothing we could get {{{ Warning: Defaulting a type to () }}} or {{{ Warning: Defaulting a type to () (use -fwarn-whatever-it-is for more detail) }}} The other thought is getting very ad-hoc, but I think we only want defaulting to `()` in an `IO a` type. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:33:40 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:29:45 2008 Subject: [GHC] #2642: Improve SpecConstr for join points In-Reply-To: <046.b2eed70c8de5c8334b5f0d2bce85500e@localhost> References: <046.b2eed70c8de5c8334b5f0d2bce85500e@localhost> Message-ID: <055.00e9ea6deacf0617a1803d48068fe7d5@localhost> #2642: Improve SpecConstr for join points --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:36:18 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:32:25 2008 Subject: [GHC] #2643: Optimized IntMap / IntSet construction from sorted input In-Reply-To: <048.5a067deefc3b5a1c5d97037f58a7321f@localhost> References: <048.5a067deefc3b5a1c5d97037f58a7321f@localhost> Message-ID: <057.d005c57740bbd0f5062a170b4d028be7@localhost> #2643: Optimized IntMap / IntSet construction from sorted input -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: containers | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:36:58 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:33:07 2008 Subject: [GHC] #2644: type of IntMap.intersection[WithKey] is incorrect In-Reply-To: <048.cdf8c7c801b2eb701f7311923129020e@localhost> References: <048.cdf8c7c801b2eb701f7311923129020e@localhost> Message-ID: <057.399501726480d3386575113015f941a8@localhost> #2644: type of IntMap.intersection[WithKey] is incorrect -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: containers | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:37:09 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:33:16 2008 Subject: [GHC] #2645: fix type, performance of IntMap(Set).findMin(Max) In-Reply-To: <048.8a9f13834a53ec09c2896007b23bea4f@localhost> References: <048.8a9f13834a53ec09c2896007b23bea4f@localhost> Message-ID: <057.31b98293f22fba475fccbbd079049b0b@localhost> #2645: fix type, performance of IntMap(Set).findMin(Max) -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: containers | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:37:26 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:33:33 2008 Subject: [GHC] #2646: Expand folding options for Sets and Maps In-Reply-To: <048.6604d7f856ddb37749ce7cc8864ce33b@localhost> References: <048.6604d7f856ddb37749ce7cc8864ce33b@localhost> Message-ID: <057.8e181880c9877e6b7e11c2e9c8bf612f@localhost> #2646: Expand folding options for Sets and Maps -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: containers | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 12:45:44 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 12:41:50 2008 Subject: [GHC] #2650: System.Process: processes may unwantedly inherit Handles on Windows when multithreading In-Reply-To: <047.1449ef20e3242d7624bded23f58b28e1@localhost> References: <047.1449ef20e3242d7624bded23f58b28e1@localhost> Message-ID: <056.e72fb708fa19ecf57409ffbee43715bc@localhost> #2650: System.Process: processes may unwantedly inherit Handles on Windows when multithreading -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/process | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:10:22 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:06:29 2008 Subject: [GHC] #2651: BlockedIndefinitely not thrown when it should be In-Reply-To: <047.e9da191bb9568ef4d909376b59b9027c@localhost> References: <047.e9da191bb9568ef4d909376b59b9027c@localhost> Message-ID: <056.647d42fe42b8987b68f51da97ef0089f@localhost> #2651: BlockedIndefinitely not thrown when it should be ------------------------------+--------------------------------------------- Reporter: govereau | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * os: MacOS X => Unknown/Multiple * architecture: x86 => Unknown/Multiple * milestone: => 6.10 branch Comment: Here's an example that doesn't need stm: {{{ module Main where import Control.Concurrent import Control.Concurrent.MVar import Control.Exception as E import System.Environment main :: IO () main = do flags <- getArgs if (length flags > 0) then do forkIO die threadDelay 10000000 else die -- expect BlockedIndefinitely exception to be thrown die :: IO () die = newEmptyMVar >>= g where g v = f v `E.catch` \e -> do print ('a', e :: E.SomeException) E.throw e f v = readMVar v }}} {{{ $ ghc n.hs -o n -fforce-recomp $ ./n ('a',thread blocked indefinitely) n: thread blocked indefinitely $ ./n q $ }}} The thread does get an exception with the threaded RTS, however: {{{ $ ghc n.hs -o n -fforce-recomp -threaded $ ./n ('a',thread blocked indefinitely) n: thread blocked indefinitely $ ./n q ('a',thread blocked indefinitely) $ }}} (the above is with the 6.10 branch) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:20:31 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:16:38 2008 Subject: [GHC] #2652: fancier prompts for ghci In-Reply-To: <043.a8f4d98c7c46b6cf0ed186a84ca3ef31@localhost> References: <043.a8f4d98c7c46b6cf0ed186a84ca3ef31@localhost> Message-ID: <052.0f92fe7ea182fde0805a5f9e08776cf4@localhost> #2652: fancier prompts for ghci ------------------------------+--------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:21:00 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:17:06 2008 Subject: [GHC] #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions In-Reply-To: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> References: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> Message-ID: <056.51eaa2ce3a2aa5e694fa3a75c425c369@localhost> #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions ------------------------------+--------------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:21:14 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:17:19 2008 Subject: [GHC] #2656: GHC API document isn't linked from any document In-Reply-To: <047.e27d233da8925cb230afc995997360c3@localhost> References: <047.e27d233da8925cb230afc995997360c3@localhost> Message-ID: <056.f765b0406aefded93850d3754e3970f5@localhost> #2656: GHC API document isn't linked from any document ------------------------------+--------------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:23:13 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:19:19 2008 Subject: [GHC] #2657: DPH Haddock document isn't linked from Libraries document In-Reply-To: <047.3ea7891160068f161ef63cd3e40d298b@localhost> References: <047.3ea7891160068f161ef63cd3e40d298b@localhost> Message-ID: <056.4c309c186f17908d7e277312284bec9a@localhost> #2657: DPH Haddock document isn't linked from Libraries document ------------------------------+--------------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:25:31 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:21:39 2008 Subject: [GHC] #2660: Add Down newtype wrapper for reversing orderings In-Reply-To: <045.b364667488af4fd3b8ece4ea98fa954f@localhost> References: <045.b364667488af4fd3b8ece4ea98fa954f@localhost> Message-ID: <054.506a8efc74e0ddb3ea5ba1217557095f@localhost> #2660: Add Down newtype wrapper for reversing orderings ------------------------------+--------------------------------------------- Reporter: twanvl | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:26:18 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:22:28 2008 Subject: [GHC] #2664: type family + data family + typeclass + type error causes GHC to diverge In-Reply-To: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> References: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> Message-ID: <053.2f5cddd2befa8a404d4a70f0ea4cd344@localhost> #2664: type family + data family + typeclass + type error causes GHC to diverge ------------------------------+--------------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:29:01 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:25:06 2008 Subject: [GHC] #2668: Standalone deriving doesn't do newtype deriving properly In-Reply-To: <044.57c98c379e66d168145ce5a2a4f71693@localhost> References: <044.57c98c379e66d168145ce5a2a4f71693@localhost> Message-ID: <053.5b27c7b4b4e8707e3471c541baf12f44@localhost> #2668: Standalone deriving doesn't do newtype deriving properly ------------------------------+--------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:42:27 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:38:33 2008 Subject: [GHC] #2669: "index out of range" error message regression In-Reply-To: <044.80e0e61ca034157992559b1b44b66761@localhost> References: <044.80e0e61ca034157992559b1b44b66761@localhost> Message-ID: <053.56a8a978cb9aaf6f3b26759942efd7c1@localhost> #2669: "index out of range" error message regression ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: None | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: We now check the Int offsets rather than the checking that we are inside the Ix range, which is presumably why the error changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:42:46 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:38:52 2008 Subject: [GHC] #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 In-Reply-To: <047.b1877ad5d06e04f09427648c52fc5225@localhost> References: <047.b1877ad5d06e04f09427648c52fc5225@localhost> Message-ID: <056.b0c589c87654adc551e92179d9e336ab@localhost> #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 ------------------------------+--------------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: time | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > $ ghci --version > The Glorious Glasgow Haskell Compilation System, version 6.8.2 > $ ghci > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> > Prelude> :m + System.Locale Data.Time.Clock Data.Time.Format > Prelude Data.Time.Format Data.Time.Clock System.Locale> parseTime > defaultTimeLocale "%y" "08" :: Ma$ > Loading package old-locale-1.0.0.0 ... linking ... done. > Loading package time-1.1.2.0 ... linking ... done. > Just 1908-01-01 00:00:00 UTC New description: {{{ $ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> Prelude> :m + System.Locale Data.Time.Clock Data.Time.Format Prelude Data.Time.Format Data.Time.Clock System.Locale> parseTime defaultTimeLocale "%y" "08" :: Ma$ Loading package old-locale-1.0.0.0 ... linking ... done. Loading package time-1.1.2.0 ... linking ... done. Just 1908-01-01 00:00:00 UTC }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:45:21 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:41:27 2008 Subject: [GHC] #2672: Provide GHC Haddock documentation at standard location In-Reply-To: <047.da2460d8d63644319f154e6a4ee65b5a@localhost> References: <047.da2460d8d63644319f154e6a4ee65b5a@localhost> Message-ID: <056.9d061f16cd0e653c1d9e275e48eb8f5f@localhost> #2672: Provide GHC Haddock documentation at standard location ------------------------------+--------------------------------------------- Reporter: nominolo | Owner: Type: task | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:49:01 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:45:08 2008 Subject: [GHC] #2675: Malformed pragma causes hang under emacs In-Reply-To: <048.1e4bef332e235556b6a741635b10a012@localhost> References: <048.1e4bef332e235556b6a741635b10a012@localhost> Message-ID: <057.b1088e505273f1377dbce1274a2d17d8@localhost> #2675: Malformed pragma causes hang under emacs -------------------------------------+-------------------------------------- Reporter: ezrakilty | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: emacs haskell-ghci-mode | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: This sounds like an emacs haskell-ghci mode bug to me (syntax highlighting not terminating or something?). Please re-open if you think GHC is doing something wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:51:54 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:48:02 2008 Subject: [GHC] #2677: Detection of TF instance conflict depends on instance order In-Reply-To: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> References: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> Message-ID: <055.ad225659897b74189de45967f415feaa@localhost> #2677: Detection of TF instance conflict depends on instance order -------------------------------------+-------------------------------------- Reporter: reinerp | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: TF instance conflict | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * owner: => chak * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the report. Manuel, sounds like one for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 13:52:21 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 13:48:32 2008 Subject: [GHC] #2679: dph build failure on Sparc Solaris 10 for ghc-6.10.0.20081007 In-Reply-To: <045.1c0db8781eff729304209aa2701e41ba@localhost> References: <045.1c0db8781eff729304209aa2701e41ba@localhost> Message-ID: <054.60c250aa31f8d6aa0e5011793ba77751@localhost> #2679: dph build failure on Sparc Solaris 10 for ghc-6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: maeder | Owner: rl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 15:07:38 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 15:03:45 2008 Subject: [GHC] #2685: Panic in harpy with GHC 6.10 RC In-Reply-To: <043.08adc09da0644f953dd1bb9dcba595d7@localhost> References: <043.08adc09da0644f953dd1bb9dcba595d7@localhost> Message-ID: <052.7fb619e75f5d11e6a66e0f9cf5a11809@localhost> #2685: Panic in harpy with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 Comment: Here's a minimal testcase: {{{ module TH (th) where import Language.Haskell.TH newtype NT = C (() -> ()) th :: Q [Dec] th = [d| foo = C undefined |] }}} {{{ module Use where import TH $( th ) }}} {{{ $ ghc --make -O -XTemplateHaskell Use [1 of 2] Compiling TH ( TH.hs, TH.o ) [2 of 2] Compiling Use ( Use.hs, Use.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081011 for x86_64-unknown-linux): mkUsage main:TH C{d} [(rz, base:GHC.Err.undefined{v rz}), (rhB, main:TH.C{d rhB}), (rhD, main:TH.th{v rhD})] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 15:15:34 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 15:11:41 2008 Subject: [GHC] #2690: Problem building HEAD when a newer version of Cabal is installed Message-ID: <044.893bccd6d8cd2bab0e7f1334217c55e7@localhost> #2690: Problem building HEAD when a newer version of Cabal is installed -----------------------+---------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- I get the following error when building HEAD. I'm using the release candidate ghc-6.10.0.20081007 from the OS X installer as the bootstrapping compiler. This seems odd since the Cabal I have in my build tree is 1.5.5; version 1.6.0.0 is installed for the bootstrapping compiler, but IIRC stage1 is supposed to be built using libraries/Cabal instead of the installed version. {{{ Configuring ghc-bin-6.11.20081011... /Users/judah/Programming/dontbackup/ghc-unvalidated/libraries/cabal-bin /usr/bin/ghc /Users/judah/Programming/dontbackup/ghc- unvalidated/libraries/bootstrapping.conf build --distpref dist-stage1 --ghc-option=-H64m --ghc-option=-O0 --ghc-option=-fasm --ghc-option=-H64m --ghc-option=-O0 --ghc-option=-fasm Preprocessing executables for ghc-bin-6.11.20081011... Building ghc-bin-6.11.20081011... [1 of 1] Compiling Main ( Main.hs, dist-stage1/build/ghc/ghc- tmp/Main.o ) Linking dist-stage1/build/ghc/ghc ... /Users/judah/Programming/dontbackup/ghc-unvalidated/utils/installPackage /install-inplace/bin/installPackage install '/Users/judah/Programming/dontbackup/ghc-unvalidated/utils/ghc-pkg /install-inplace/bin/ghc-pkg' 'XXX/package.conf' "" \ /Users/judah/Programming/dontbackup/ghc- unvalidated/ghc/stage1-inplace \ /Users/judah/Programming/dontbackup/ghc- unvalidated/ghc/stage1-inplace \ '$prefix' \ '/Users/judah/Programming/dontbackup/ghc- unvalidated/inplace-datadir' \ '$prefix/libexec' \ '$prefix/dynlib' \ '/Users/judah/Programming/dontbackup/ghc- unvalidated/inplace-datadir' \ '$prefix/doc' \ '$prefix/html' \ '$prefix/haddock' \ --distpref dist-stage1 \ --disable-executable-stripping \ --enable-shell-wrappers installPackage: You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.5.5, now Cabal-1.6.0.0). make[2]: *** [build.stage.1] Error 1 make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 15:41:00 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 15:37:06 2008 Subject: [GHC] #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 In-Reply-To: <047.b1877ad5d06e04f09427648c52fc5225@localhost> References: <047.b1877ad5d06e04f09427648c52fc5225@localhost> Message-ID: <056.d0118bc9da0fffcd9cb46315b06c05d4@localhost> #2671: Data.Time.Clock parseTime's %y parses "08" as 1908 -------------------------------+-------------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: time | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Comment (by simonmic): I see this on both mac osx leopard and ubuntu hardy. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 16:53:26 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 16:49:34 2008 Subject: [GHC] #2689: make maintainer-clean leaves generated files and directories In-Reply-To: <044.d82e9d076aeb3a76dac009bdaa86249d@localhost> References: <044.d82e9d076aeb3a76dac009bdaa86249d@localhost> Message-ID: <053.9f32fae299fa0ba1d41d9bec69ae5158@localhost> #2689: make maintainer-clean leaves generated files and directories ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 17:00:14 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 16:56:19 2008 Subject: [GHC] #2658: Extreme memory usage In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.19a6185b6f60ab104903133491c25e3f@localhost> #2658: Extreme memory usage -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------------+-------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 17:03:03 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 16:59:10 2008 Subject: [GHC] #2063: Breackage on OpenBSD due to mmap remap In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.4d828fafcdfa155a36fd78e2606a3d5f@localhost> #2063: Breackage on OpenBSD due to mmap remap ----------------------------+----------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown/Multiple Os: OpenBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 17:03:27 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 16:59:34 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.bea5314162c66dbf9c2122680b58d1f3@localhost> #2337: Data.Array documentation utterly broken ------------------------------+--------------------------------------------- Reporter: japple | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: reopened => new * owner: => igloo Comment: I'll fix this with copy/paste in the 6.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 17:49:21 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 17:45:26 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.7d9850f1ae15bc18e5f9fe9eed2b9ded@localhost> #2081: GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 17:58:31 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 17:54:48 2008 Subject: [GHC] #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown-linux-libedit2 Message-ID: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown- linux-libedit2 -----------------------+---------------------------------------------------- Reporter: dancor | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- ~ stty stop '' ~ # ^S prints literal ^S ~ cat a.hs main = return () ~ ghc --make a.hs ~ ./a ~ # ^S still prints literal ^S ~ runghc a.hs ~ # but now, ^S sends XOFF to terminal Happens in console/xterm/urxvt and in/not-in gnu screen. Haven't seen this in any previous versions of ghc. ~ uname -a Linux pima 2.6.25-2-686 #1 SMP Fri Jul 18 17:46:56 UTC 2008 i686 GNU/Linux ~ # debian lenny -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 18:02:17 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 17:58:28 2008 Subject: [GHC] #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown-linux-libedit2 In-Reply-To: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> References: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> Message-ID: <054.054ef630c91ed0830d368f87f85b0d69@localhost> #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown- linux-libedit2 -------------------------+-------------------------------------------------- Reporter: dancor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by dancor): Oops, failed trac formatting. Don't know how to edit original report but Description should be: {{{ ~ stty stop '' ~ # ^S prints literal ^S ~ cat a.hs main = return () ~ ghc --make a.hs ~ ./a ~ # ^S still prints literal ^S ~ runghc a.hs ~ # but now, ^S sends XOFF to terminal }}} Happens in console/xterm/urxvt and in/not-in gnu screen. Haven't seen this in any previous versions of ghc. {{{ ~ uname -a Linux pima 2.6.25-2-686 #1 SMP Fri Jul 18 17:46:56 UTC 2008 i686 GNU/Linux ~ # debian lenny }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 18:39:33 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 18:35:50 2008 Subject: [GHC] #2584: Pretty printing of types with HsDocTy goes wrong In-Reply-To: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> References: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> Message-ID: <060.9928cf9f43cc555df5601fe9398c6c41@localhost> #2584: Pretty printing of types with HsDocTy goes wrong ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: waern Type: bug | Status: assigned Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 18:43:47 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 18:39:57 2008 Subject: [GHC] #2677: Detection of TF instance conflict depends on instance order In-Reply-To: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> References: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> Message-ID: <055.9a345bfc39f89c8804657817d9c65927@localhost> #2677: Detection of TF instance conflict depends on instance order -------------------------------------+-------------------------------------- Reporter: reinerp | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: TF instance conflict | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 12 18:56:58 2008 From: trac at galois.com (GHC) Date: Sun Oct 12 18:53:16 2008 Subject: [GHC] #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown-linux-libedit2 In-Reply-To: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> References: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> Message-ID: <054.d83a81739ec2215c90995f93137fd5ad@localhost> #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown- linux-libedit2 -------------------------+-------------------------------------------------- Reporter: dancor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by judah): Hm, I can't reproduce this on OS X with either Terminal.app, xterm or urxvt. Can you post the output of {{{stty -a}}} before and after the {{{stty stop ''}}}, and after the {{{runghc a.hs}}}, in the above sequence of commands? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 05:13:32 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 05:09:40 2008 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc Message-ID: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -----------------------+---------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: sparc | Os: Solaris -----------------------+---------------------------------------------------- My attempt to build ghc-6.10.0.20081007 on a sparc created a stage2 compiler that seq-faults. I don't have much time (and no idea how) to continue: {{{ cabal-bin: ghc version >=6.4 is required but the version of /export/local2/home/maeder/haskell/ghc-6.10.0.20081007/ghc/stage2-inplace/ghc could not be determined. gmake[3]: *** [with-stage-2] Error 1 gmake[3]: Leaving directory `/export/local2/home/maeder/haskell/ghc-6.10.0.20081007/utils/installPackage' gmake[2]: *** [with-stage-2.installPackage] Error 2 gmake[2]: Leaving directory `/export/local2/home/maeder/haskell/ghc-6.10.0.20081007/utils' gmake[1]: *** [stage2] Error 2 gmake[1]: Leaving directory `/export/local2/home/maeder/haskell/ghc-6.10.0.20081007' gmake: *** [bootstrap2] Error 2 }}} {{{ -bash-3.00$ /export/local2/home/maeder/haskell/ghc-6.10.0.20081007/ghc/stage2-inplace/libexec/ghc ghc: missing -B option Segmentation Fault }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 05:18:24 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 05:14:28 2008 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.c011e5d53661818eacb728b61d4bc5fd@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: sparc | Os: Solaris -------------------------+-------------------------------------------------- Comment (by maeder): {{{ Starting program: /export/local2/home/maeder/haskell/ghc-6.10.0.20081007/ghc/stage2-inplace/libexec/ghc warning: Lowest section in /lib/libdl.so.1 is .hash at 000000b4 warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074 [New LWP 1] [New LWP 2] [New LWP 3] ghc: missing -B option Program received signal SIGSEGV, Segmentation fault. 0x0132a6b0 in todo_block_full () (gdb) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 06:42:12 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 06:38:20 2008 Subject: [GHC] #2687: Lexical error when compiling unicode-prelude-0.1 using GHC 6.10.1 RC1 In-Reply-To: <049.bc4576b09ee6219e664f054b11cec9bf@localhost> References: <049.bc4576b09ee6219e664f054b11cec9bf@localhost> Message-ID: <058.e4cbf9c253046d71bd06680980468d1a@localhost> #2687: Lexical error when compiling unicode-prelude-0.1 using GHC 6.10.1 RC1 ------------------------+--------------------------------------------------- Reporter: albertfong | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ------------------------+--------------------------------------------------- Comment (by simonmar): I presume this broke because we updated our Unicode data between 6.8.3 and 6.10. I propose we add `OtherPunctuation`, `ConnectorPunctuation` and `DashPunctuation` to the symbol class. We should leave the brackets and quotes in other_graphic for now, because these will be useful for new syntax later (e.g. we'll probably want to use the syntax brackets for Template Haskell). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 06:43:31 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 06:39:36 2008 Subject: [GHC] #2685: Panic in harpy with GHC 6.10 RC In-Reply-To: <043.08adc09da0644f953dd1bb9dcba595d7@localhost> References: <043.08adc09da0644f953dd1bb9dcba595d7@localhost> Message-ID: <052.b1bc0166bc38dc19ced7734a94f42469@localhost> #2685: Panic in harpy with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: `mkUsage` is my area these days... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 06:59:45 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 06:55:49 2008 Subject: [GHC] #2682: Keep going after failed search for module in current directory In-Reply-To: <042.3ab3a08a92cd2130db77f37efdac62b0@localhost> References: <042.3ab3a08a92cd2130db77f37efdac62b0@localhost> Message-ID: <051.04c928587bd0e2045a3a9dc7593f4336@localhost> #2682: Keep going after failed search for module in current directory ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): The problem is that the source code for the module is found on the search path, and GHCi knows that you haven't loaded it with `:load`. So in this case we could indeed decide to use the package version of the module instead, but that might be a bit strange too: doing `import M` would have different behaviour before and after using `:load M`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 07:09:41 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 07:05:45 2008 Subject: [GHC] #2680: Type-checking performance regression In-Reply-To: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> References: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> Message-ID: <053.36d3d4c59ecf8936608c8aa6402de31d@localhost> #2680: Type-checking performance regression ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Comment (by simonmar): Replying to [comment:4 igloo]: > The problem is in the creation of `ent_map` in `iface/MkIface:mk_usage_info`. In this case, all of the `mod`s are the same, so `extendModuleEnv_C (++) mv_map mod [occ]` builds the list of them quadratically. Using `(flip (++))` brings the time down to a couple of seconds. It doesn't look to me like the order of elements should be important here, but can you confirm please? > {{{ > hunk ./compiler/iface/MkIface.lhs 821 > - Just mod -> extendModuleEnv_C (++) mv_map mod [occ] > + Just mod -> extendModuleEnv_C (flip (++)) mv_map mod [occ] > }}} Nice catch! That should be fine, although it's only a few extra characters to write {{{ extendModuleEnv_C (\xs _ -> occ:xs) mv_map mod [occ] }}} which is a tad more efficient, and clearer to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 07:27:45 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 07:23:49 2008 Subject: [GHC] #2563: With -N4: "internal error: RELEASE_LOCK: I do not own this lock: Task.c 269" In-Reply-To: <044.a34da6c43bb4e28144648cb6864c37dc@localhost> References: <044.a34da6c43bb4e28144648cb6864c37dc@localhost> Message-ID: <053.1a91a09bb409109dddf67b58b0b11ac6@localhost> #2563: With -N4: "internal error: RELEASE_LOCK: I do not own this lock: Task.c 269" ----------------------+----------------------------------------------------- Reporter: TomMD | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: This works fine with 6.10 (actually it was probably #2192 that fixed it, in 6.8.3). Incedentally, if you want the program to really work in parallel, you'll have to change the definition of `hashAndPrint` to something like this: {{{ hashAndPrint str f = do bs <- L.readFile f let z = f ++ ": " ++ show (md5 bs) seq (length z) $ putMVar str z }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 08:26:54 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 08:22:58 2008 Subject: [GHC] #2624: GHC 10.1 beta build error In-Reply-To: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> References: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> Message-ID: <056.d03b3cc0c0eed373fb14001128be682b@localhost> #2624: GHC 10.1 beta build error ----------------------+----------------------------------------------------- Reporter: humasect | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: fixed => * milestone: => 6.10.1 Comment: This has the same smell as #2081. We don't know if it's fixed in 6.10.1 until we try to build 6.10.1 with itself, and presumably we can't do that because the people experiencing the problem can't build 6.10.1 at all? Can we please continue to investigate this one until we know what the cause is. -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Mon Oct 13 08:31:15 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Oct 13 08:27:23 2008 Subject: TypeCompose Patch In-Reply-To: References: <5154.24.69.170.39.1222276110.squirrel@squishy.internetofdeath.com> <5614.24.69.170.39.1222291451.squirrel@squishy.internetofdeath.com> <6268.24.69.170.39.1222292558.squirrel@squishy.internetofdeath.com> <20080925005001.GC18545@gmx.de> <638ABD0A29C8884A91BC5FB5C349B1C32D766E2F95@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76A78B6C@EA-EXMSG-C334.europe.corp.microsoft.com> I believe it's fixed in HEAD and 6.10; I recall Manuel saying he'd done it, the same day I told him. (I thought I'd created a Trac ticket for it, but I don't seem to have done so.) (Worth noting for future: if you create a ticket you can follow the history more easily.) As to the "my linear map implementation, but not when it tickles a ghc bug for me and for readers", do we have a Trac ticket for that? I don't know what the bug is, nor whether it's fixed. Simon From: conal.elliott@gmail.com [mailto:conal.elliott@gmail.com] On Behalf Of Conal Elliott Sent: 12 October 2008 06:36 To: Simon Peyton-Jones Cc: glasgow-haskell-bugs@haskell.org Subject: Re: TypeCompose Patch What's the status of this bug? I'd like to know when it's safe to upgrade to a new ghc. Also, I want to blog about my linear map implementation, but not when it tickles a ghc bug for me and for readers. Thanks, - Conal 2008/9/25 Simon Peyton-Jones > Conal, Marc This is definitely a bug in the new equality-solving mechanism. I can reproduce it readily. I'll discuss it with Manuel tomorrow and get back to you. Thanks for finding it! Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs- | bounces@haskell.org] On Behalf Of Marc Weber | Sent: 25 September 2008 01:50 | To: glasgow-haskell-bugs@haskell.org | Subject: Re: TypeCompose Patch | | On Wed, Sep 24, 2008 at 02:55:01PM -0700, Conal Elliott wrote: | > Eep! That code (which uses type classes) fails to compile under 6.8.3 | but | > does compile under 6.9. Looks like 6.10 broke something. | > | > Can anyone else check whether vector-space build or breaks under 6.10? | > The repo is | > | > [1]http://code.haskell.org/vector-space/ | | src/Data/LinearMap.hs|37 col 21 error| | || Couldn't match expected type `t' against inferred type `Basis u' | || In the second argument of `(.)', namely `basisValue' | || In the first argument of `trie', namely `(f . basisValue)' | || In the expression: trie (f . basisValue) | | Hi Conal, I'm getting the error above (current ghc from darcs) | If you want I can give you an ssh account where this ghc version is | installed within the next days. | | I also had to add a -fglasgow-exts to a MemoTrie file.. | (Not sure which is the correct language extension which was missing) | | Sincerly | Marc Weber | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20081013/ed5412ba/attachment.htm From trac at galois.com Mon Oct 13 08:32:54 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 08:29:03 2008 Subject: [GHC] #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint In-Reply-To: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> References: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> Message-ID: <060.93962006194c2a7b4a85c3da2f735e15@localhost> #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint ------------------------------+--------------------------------------------- Reporter: PVerswyvelen | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => chak Comment: Manuel: I think this is in your current patch. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 08:37:28 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 08:33:36 2008 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.4dd368ce1a332149dcf4f4fbb6e185e9@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Could you try re-linking stage2 with `-debug`, which should get you a better stack trace. {{{ $ cd ghc $ make rebuild stage=2 GhcDebugged=YES }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 08:39:21 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 08:35:28 2008 Subject: [GHC] #2624: GHC 10.1 beta build error In-Reply-To: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> References: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> Message-ID: <056.fbb3bf71a480661e373b8800e6640f79@localhost> #2624: GHC 10.1 beta build error ----------------------+----------------------------------------------------- Reporter: humasect | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by igloo): I have an e-mail from humasect saying {{{ This compiled and installed perfectly, ghc-6.10.0.20080927 snapshot found in the same place. It was fixed either in your packaging, or between 21-27 snapshots? Also, thanks! }}} ("This" refering to http://www.haskell.org/ghc/dist/stable/dist/GHC-6.10.0.20080921-i386.pkg) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 08:49:42 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 08:45:47 2008 Subject: [GHC] #2685: Panic in harpy with GHC 6.10 RC In-Reply-To: <043.08adc09da0644f953dd1bb9dcba595d7@localhost> References: <043.08adc09da0644f953dd1bb9dcba595d7@localhost> Message-ID: <052.8c1c0662e4a4ddc29642a1b67cd4202c@localhost> #2685: Panic in harpy with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Mon Oct 13 13:13:39 BST 2008 Simon Marlow * Fix #2685: two Bool arguments to tidyTypeEnv were the wrong way around So -XTemplateHaskell was behaving like -fomit-interface-file-pragmas, and vice versa. }}} A good one to find before the release! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 09:05:16 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 09:01:22 2008 Subject: [GHC] #2636: Error message for missing import substantially worse in 6.9/6.11 In-Reply-To: <051.f86bb43b82a519168d8fbe26645dafad@localhost> References: <051.f86bb43b82a519168d8fbe26645dafad@localhost> Message-ID: <060.7ee07b8559a6254bf4eb9f33bdfd7fa9@localhost> #2636: Error message for missing import substantially worse in 6.9/6.11 ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 09:05:47 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 09:01:50 2008 Subject: [GHC] #2319: STM not as fair as it could be In-Reply-To: <044.81823a3e2ec18990aac9bedd6527630b@localhost> References: <044.81823a3e2ec18990aac9bedd6527630b@localhost> Message-ID: <053.e101cbb4896e94d3e4d897dc039c8753@localhost> #2319: STM not as fair as it could be ------------------------------+--------------------------------------------- Reporter: josef | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 09:37:40 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 09:33:45 2008 Subject: [GHC] #2663: STM crash with -N2+ In-Reply-To: <047.219f416ad1bdd20d414e29dc76d8c549@localhost> References: <047.219f416ad1bdd20d414e29dc76d8c549@localhost> Message-ID: <056.43417d8d0b46aa188ae49b7e2ac1ade1@localhost> #2663: STM crash with -N2+ ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 10:06:54 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 10:02:58 2008 Subject: [GHC] #2624: GHC 10.1 beta build error In-Reply-To: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> References: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> Message-ID: <056.c5a03d400a50a7b31b6c3ce3285faa1c@localhost> #2624: GHC 10.1 beta build error ----------------------+----------------------------------------------------- Reporter: humasect | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => fixed Comment: Ok, so this bug is either fixed or not reproducible any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 10:45:56 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 10:42:07 2008 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.28548155a8f8ca87a0b62553add1340c@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Comment (by maeder): it shows now: {{{ [New LWP 3] ghc: missing -B option ghc: internal error: ASSERTION FAILED: file sm/GCUtils.c, line 140 (GHC version 6.10.0.20081007 for sparc_sun_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0xff14642c in _lwp_kill () from /lib/libc.so.1 (gdb) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 10:47:20 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 10:43:23 2008 Subject: [GHC] #2685: Panic in harpy with GHC 6.10 RC In-Reply-To: <043.08adc09da0644f953dd1bb9dcba595d7@localhost> References: <043.08adc09da0644f953dd1bb9dcba595d7@localhost> Message-ID: <052.6816bdc5d7a564f23c5df4919ac59220@localhost> #2685: Panic in harpy with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 13:56:54 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 13:52:58 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.86bb51a3ab37641301fd433d80dfdd9a@localhost> #2337: Data.Array documentation utterly broken ------------------------------+--------------------------------------------- Reporter: japple | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch Comment: Hmm, not so simple. I've just unhidden GHC.Arr in the 6.10 branch. Unfortunately, we can't link there from Data.Array due to http://trac.haskell.org/haddock/ticket/13 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 14:17:02 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 14:13:45 2008 Subject: [GHC] #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown-linux-libedit2 In-Reply-To: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> References: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> Message-ID: <054.e38d2f24d1aaac3fd4691bd4e2cb065b@localhost> #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown- linux-libedit2 -------------------------+-------------------------------------------------- Reporter: dancor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by dancor): In xterm without gnu screen (running under openbox on xorg; no kde or gnome): {{{ ~ stty -a | tee stty.1 speed 38400 baud; rows 61; columns 213; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke ~ stty stop '' ~ stty -a | tee stty.2 speed 38400 baud; rows 61; columns 213; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke ~ runghc a.hs ~ stty -a | tee stty.3 speed 38400 baud; rows 61; columns 213; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke ~ diff stty.1 stty.2 ~ diff stty.2 stty.3 --- stty.2 2008-10-13 11:12:44.000000000 -0700 +++ stty.3 2008-10-13 11:12:53.000000000 -0700 @@ -1,7 +1,7 @@ speed 38400 baud; rows 61; columns 213; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; -eol2 = ; swtch = ; start = ^Q; stop = ; susp = ^Z; -rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; +eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; +werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 15:44:41 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 15:41:27 2008 Subject: [GHC] #2437: More accurate package dependencies In-Reply-To: <047.68fd28011c214b441523af716564e799@localhost> References: <047.68fd28011c214b441523af716564e799@localhost> Message-ID: <056.d92633ae5d1fbcdd4286be6bf087e7ae@localhost> #2437: More accurate package dependencies ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by morrow): * cc: mjm2002@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 16:04:18 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 16:00:21 2008 Subject: [GHC] #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 Message-ID: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 ---------------------------+------------------------------------------------ Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: major Keywords: panic | Testcase: Architecture: x86 | Os: Windows ---------------------------+------------------------------------------------ The following file (DM.hs) panics GHC 6.10 with this error message: c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ c:\ghc\ghc-6.10.0.20081007\bin\ghc.exe ~/DM.hs ghc.exe: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for i386-unknown-mingw32): TcTyFuns.uMeta: normalisation shouldn't allow x ~ x Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug --Ben ---- DM.hs ---- {-# LANGUAGE GADTs, TypeFamilies #-} type family TFn a :: * data PVR a = PVR {pvrX :: Int} deriving (Eq) f :: () -> Maybe (TFn a) f _ = undefined g :: Maybe () g = do pvs <- mapM f undefined let n = (map pvrX pvs) `min` (map pvrX pvs) undefined ---- DM.hs ---- Other info: c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ c:\ghc\ghc-6.10.0.20081007\bin\ghc-pkg.exe list c:/ghc/ghc-6.10.0.20081007\package.conf: Cabal-1.5.5, HUnit-1.2.0.0, QuickCheck-1.1.0.0, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, bytestring-0.9.1.4, containers-0.2.0.0, directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), filepath-1.1.0.1, (ghc-6.10.0.20081007), ghc-prim-0.1.0.0, haddock-2.2.2, haskell-src-1.0.1.2, haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.1, integer-0.1.0.0, mtl-1.1.0.1, network-2.2.0.0, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.0.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.1, (syb-0.1.0.0), template-haskell-2.3.0.0, time-1.1.2.1, xhtml-3000.2.0.1 c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ c:\ghc\ghc-6.10.0.20081007\bin\ghc.exe -v Glasgow Haskell Compiler, Version 6.10.0.20081007, for Haskell 98, stage 2 booted by GHC version 6.8.3 Using package config file: C:\ghc\ghc-6.10.0.20081007\package.conf hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.0 wired-in package base mapped to base-4.0.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.0 wired-in package template-haskell mapped to template-haskell-2.3.0.0 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc.exe: no input files Usage: For basic information, try the `--help' option. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 16:28:52 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 16:24:54 2008 Subject: [GHC] #2694: Building GHC 6.10 with Cabal 1.6 fails due to in-tree Cabal 1.5.5 Message-ID: <043.74586645854c8ad208c6aecff658335f@localhost> #2694: Building GHC 6.10 with Cabal 1.6 fails due to in-tree Cabal 1.5.5 ---------------------------------+------------------------------------------ Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ If you've installed Cabal 1.6 (as we're recommending) GHC won't build, falling over at, {{{ /home/dons/ghc-6.10/build/utils/installPackage/install- inplace/bin/installPackage install '/home/dons/ghc-6.10/build/utils/ghc-pkg/install- inplace/bin/ghc-pkg' installPackage: You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.5.5, now Cabal-1.6.0.1) }}} Working out if this really is a correctness issue seems a good idea -- maybe we can lift this restriction, since it seems likely people will in the future have newer cabals than the one ghc ships with today. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 21:09:47 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 21:05:50 2008 Subject: [GHC] #2695: bogus "syntactically distinct contexts" error Message-ID: <044.f308f1282aefb65817439a6f79a47353@localhost> #2695: bogus "syntactically distinct contexts" error ---------------------------------+------------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ {{{ {-# LANGUAGE TypeOperators, FlexibleContexts , MultiParamTypeClasses, FunctionalDependencies , TypeFamilies -- , ScopedTypeVariables #-} -- The ScopedTypeVariables is there just as a bug work-around. Without: -- -- Mutually dependent functions have syntactically distinct contexts -- When matching the contexts of the signatures for -- dZero :: forall b a s. -- (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) => -- a :> b -- pureD :: forall b a s. -- (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) => -- b -> a :> b -- The signature contexts in a mutually recursive group should all be identical -- When generalising the type(s) for dZero, pureD -- -- This bug was introduced between ghc 6.9.20080622 and 6.10.0.20081007. {-# OPTIONS_GHC -fno-warn-missing-methods #-} import Control.Applicative class AdditiveGroup v where zeroV :: v (^+^) :: v -> v -> v negateV :: v -> v class AdditiveGroup v => VectorSpace v s | v -> s where (*^) :: s -> v -> v -- | Mapping from all elements of @a@ to the results of some function class HasTrie a where data (:->:) a :: * -> * instance HasTrie a => Functor ((:->:) a) instance HasTrie a => Applicative ((:->:) a) class VectorSpace v s => HasBasis v s where type Basis v :: * -- | Linear map, represented a as a memo function from basis to values. type u :-* v = Basis u :->: v data a :> b = D { powVal :: b, derivative :: a :-* (a :> b) } dZero :: (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) => a:>b dZero = pureD zeroV pureD :: (AdditiveGroup b, HasBasis a s, HasTrie (Basis a)) => b -> a:>b pureD b = b `D` pure dZero }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 21:15:36 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 21:11:37 2008 Subject: [GHC] #2696: forall not recognized in RULES Message-ID: <044.12be41e0f2e44b9a71e12eafba7f0064@localhost> #2696: forall not recognized in RULES ---------------------------------+------------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ {{{ {-# LANGUAGE GADTs, TypeFamilies, TypeOperators -- , ScopedTypeVariables #-} {-# OPTIONS_GHC -Wall -frewrite-rules #-} -- ScopedTypeVariables works around a 6.10 bug. The forall keyword is -- supposed to be recognized in a RULES pragma, but it's not. -- -- This bug was introduced between ghc 6.9.20080622 and 6.10.0.20081007. -- | Mapping from all elements of @a@ to the results of some function class HasTrie a where -- | Representation of trie with domain type @a@ data (:->:) a :: * -> * -- Create the trie for the entire domain of a function trie :: (a -> b) -> (a :->: b) -- | Convert a trie to a function, i.e., access a field of the trie untrie :: (a :->: b) -> (a -> b) {-# RULES "trie/untrie" forall t. trie (untrie t) = t "untrie/trie" forall f. untrie (trie f) = f #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 21:16:25 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 21:12:26 2008 Subject: [GHC] #2695: bogus "syntactically distinct contexts" error In-Reply-To: <044.f308f1282aefb65817439a6f79a47353@localhost> References: <044.f308f1282aefb65817439a6f79a47353@localhost> Message-ID: <053.6bef0042b56110e3d40fb2d539b8c1cf@localhost> #2695: bogus "syntactically distinct contexts" error ---------------------------------+------------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by conal): see also bug #2696 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 21:16:42 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 21:12:44 2008 Subject: [GHC] #2696: forall not recognized in RULES In-Reply-To: <044.12be41e0f2e44b9a71e12eafba7f0064@localhost> References: <044.12be41e0f2e44b9a71e12eafba7f0064@localhost> Message-ID: <053.2988cb40ccbd6eda3cacc2ad91c52546@localhost> #2696: forall not recognized in RULES ---------------------------------+------------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by conal): see also bug #2695 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 13 23:15:28 2008 From: trac at galois.com (GHC) Date: Mon Oct 13 23:11:31 2008 Subject: [GHC] #2696: forall not recognized in RULES In-Reply-To: <044.12be41e0f2e44b9a71e12eafba7f0064@localhost> References: <044.12be41e0f2e44b9a71e12eafba7f0064@localhost> Message-ID: <053.4eb5deda07522d485e69b94bf13cc680@localhost> #2696: forall not recognized in RULES ---------------------------------+------------------------------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by duncan): See also bug #2497 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 00:40:12 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 00:36:58 2008 Subject: [GHC] #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown-linux-libedit2 In-Reply-To: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> References: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> Message-ID: <054.58739fea433dd3a0eba3a78e5a051d98@localhost> #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown- linux-libedit2 -------------------------+-------------------------------------------------- Reporter: dancor | Owner: judah Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by judah): * owner: => judah Comment: OK, thanks, I can reproduce it now. The trick to reproducing it on my system was to use {{{stty stop undef}}} instead of {{{stty stop ''}}}. I'm looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 01:30:28 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 01:26:34 2008 Subject: [GHC] #2679: dph build failure on Sparc Solaris 10 for ghc-6.10.0.20081007 In-Reply-To: <045.1c0db8781eff729304209aa2701e41ba@localhost> References: <045.1c0db8781eff729304209aa2701e41ba@localhost> Message-ID: <054.f77cacd54d2a233c66fa98c1b3883550@localhost> #2679: dph build failure on Sparc Solaris 10 for ghc-6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: maeder | Owner: rl Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by rl): * status: assigned => closed * resolution: => fixed Comment: This should be fixed by this patch to package dph: Fri Oct 10 01:44:18 PDT 2008 Roman Leshchinskiy * Use $(CPP) instead of cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 04:00:45 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 03:56:49 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.e785a5ffce8e7b7b45f9450ed0375977@localhost> #2337: Data.Array documentation utterly broken ------------------------------+--------------------------------------------- Reporter: japple | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): That Haddock bug only applies to references to modules from inside documentation, so the hyperlinks for the actual names should still work, right? Also, could we do something like this: {{{ module Data.Array where import qualified GHC.Arr -- | .. documentation for 'array' array = GHC.Arr.array }}} only works for functions, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 04:03:04 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 03:59:32 2008 Subject: [GHC] #2437: More accurate package dependencies In-Reply-To: <047.68fd28011c214b441523af716564e799@localhost> References: <047.68fd28011c214b441523af716564e799@localhost> Message-ID: <056.ccd46d9026f25107e1976ab05a01e55c@localhost> #2437: More accurate package dependencies ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Old description: > The problem we want to solve here is that there is currently no > distinction between compile-time package dependencies and link-time > package dependencies. Often a compile-time dependency is also a link- > time dependency, but there are two instances in which it might not be: > > * Template Haskell: some packages might be required for executing TH > code at > compile-time, but the compiled code doesn't require those packages to > be > linked in. > > * Attributes: we're considering allowing arbitrary attributes to be > attached > to declarations, where the attributes are compile-time Haskell > expressions. > The same issue as with TH crops up again here. > > Currently we figure out which packages to link by looking at the > (transitive closure of the) imports. It would be better to look at the > external references of the compiled code; some of the packages referred > to by imports may not need to be linked. > > Similarly, we should figure out the dependencies of a ``package`` by > taking the union of the link-time dependencies of its compiled modules. > This means a small changes to Cabal. > > None of this is particularly hard, and doesn't need any changes to the > interface file format or package database: we just record fewer package > dependencies than before. The only tricky bit is traversing the code to > figure out what the package dependencies should be. New description: The problem we want to solve here is that there is currently no distinction between compile-time package dependencies and link-time package dependencies. Often a compile-time dependency is also a link-time dependency, but there are two instances in which it might not be: * Template Haskell: some packages might be required for executing TH code at compile-time, but the compiled code doesn't require those packages to be linked in. * [wiki:Annotations]: we're considering allowing arbitrary attributes to be attached to declarations, where the attributes are compile-time Haskell expressions. The same issue as with TH crops up again here. Currently we figure out which packages to link by looking at the (transitive closure of the) imports. It would be better to look at the external references of the compiled code; some of the packages referred to by imports may not need to be linked. Similarly, we should figure out the dependencies of a ``package`` by taking the union of the link-time dependencies of its compiled modules. This means a small changes to Cabal. None of this is particularly hard, and doesn't need any changes to the interface file format or package database: we just record fewer package dependencies than before. The only tricky bit is traversing the code to figure out what the package dependencies should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 07:36:37 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 07:32:39 2008 Subject: [GHC] #2658: Extreme memory usage (probably type functions) In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.4047d97d5fe0ed279c10aeb3ee37f250@localhost> #2658: Extreme memory usage (probably type functions) -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------------+-------------------------------------- Changes (by simonmar): * summary: Extreme memory usage => Extreme memory usage (probably type functions) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 08:00:08 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 07:56:10 2008 Subject: [GHC] #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 In-Reply-To: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> References: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> Message-ID: <058.127382921a1fb0d42ce4298b64c08be3@localhost> #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 ---------------------------+------------------------------------------------ Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: panic | Testcase: Architecture: x86 | Os: Windows ---------------------------+------------------------------------------------ Comment (by BenMoseley): I had a chance to simplify this some more: {{{ {-# LANGUAGE TypeFamilies #-} type family TFn a :: * f :: Maybe () f = do let Just x = undefined :: Maybe (TFn a) let n = fst x + fst x return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 10:44:44 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 10:40:49 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.fb11eddd7221e7b1a73669068f156fca@localhost> #1876: Complete shared library support ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by clemens): I fixed the following for Linux/x86_64 (probably also other archs) in today's HEAD "./configure --enable-shared; make" should compile error free. It should give you all libraries as shared objects, including a stage2 GHC package. The GHC package should be linkable into a working ghc binary (including a wrapper) that also works in interactive mode. Running the testsuits gives a few isolated regressions in ghci and template haskell I still have to dig into. I won't go into details about the Windows status. At the moment, linking the RTS dies with unresolved RTS __imp__* symbols. Linking the RTS with its own import lib (libHSrts*.dll.a) should fix the problem, but I haven't got there yet. However, for libgmp on Windows, we need to apply the same trick as with libffi, namely change it into a Haskell package. Most of the hacking was already done for libffi, so the changes from libffi/Makefile could be worked into gmp/Makefile without much trouble, I think. In any case, I'd like to argue that we should give priority to Linux dynamic linking. With this I mean that we ship dynamic lib support even if it's just for this single architecture. This will help to build up a small user base that will hopefully report regressions as soon as they pop up. Also Linux is the most hassle free OS when it comes to dynamic library linking, so it is easier to establish that as base camp for further climbing. Except for libffi change, most of the changes are quite minimal. We could probably target 6.10.2 as milestone for merging this into stable. On Linux x86-64 dynamic at the moment: {{{ Unexpected failures: 2014(normal) T2386(normal) T2597a(normal) T2597b(normal) TH_genEx(normal) TH_spliceD1(normal) TH_spliceDecl3(normal) TH_spliceDecl4(normal) TH_spliceE5(normal) prog001(ghci) prog002(ghci) prog003(ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 12:33:30 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 12:29:43 2008 Subject: [GHC] #2664: type family + data family + typeclass + type error causes GHC to diverge In-Reply-To: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> References: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> Message-ID: <053.8afa054b00e4088ed8cbf792c894b336@localhost> #2664: type family + data family + typeclass + type error causes GHC to diverge ------------------------------+--------------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: high => normal Comment: Type-family-related bugs aren't release critical -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 12:33:25 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 12:29:51 2008 Subject: [GHC] #2677: Detection of TF instance conflict depends on instance order In-Reply-To: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> References: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> Message-ID: <055.e8eeb16752a046b16b3545ff47e9e7da@localhost> #2677: Detection of TF instance conflict depends on instance order -------------------------------------+-------------------------------------- Reporter: reinerp | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: TF instance conflict | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * priority: high => normal Comment: Type-family-related bugs aren't release critical -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 12:35:43 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 12:31:43 2008 Subject: [GHC] #2656: GHC API document isn't linked from any document In-Reply-To: <047.e27d233da8925cb230afc995997360c3@localhost> References: <047.e27d233da8925cb230afc995997360c3@localhost> Message-ID: <056.edcdfca332e9e8b63b5a8dc7745144bc@localhost> #2656: GHC API document isn't linked from any document ------------------------------+--------------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've added some links, in HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 12:35:45 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 12:31:48 2008 Subject: [GHC] #2672: Provide GHC Haddock documentation at standard location In-Reply-To: <047.da2460d8d63644319f154e6a4ee65b5a@localhost> References: <047.da2460d8d63644319f154e6a4ee65b5a@localhost> Message-ID: <056.9d2b739567c736d7f90a86027adc855b@localhost> #2672: Provide GHC Haddock documentation at standard location ------------------------------+--------------------------------------------- Reporter: nominolo | Owner: Type: task | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by igloo): Now fixed in HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 12:36:42 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 12:32:42 2008 Subject: [GHC] #2672: Provide GHC Haddock documentation at standard location In-Reply-To: <047.da2460d8d63644319f154e6a4ee65b5a@localhost> References: <047.da2460d8d63644319f154e6a4ee65b5a@localhost> Message-ID: <056.24226263c3b809de6400d97a32feeda9@localhost> #2672: Provide GHC Haddock documentation at standard location ------------------------------+--------------------------------------------- Reporter: nominolo | Owner: Type: task | Status: closed Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 14:48:47 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 14:44:50 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.25c54579b82b3fe8d0ae8e11927d7ac8@localhost> #2337: Data.Array documentation utterly broken ------------------------------+--------------------------------------------- Reporter: japple | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by igloo): Replying to [comment:18 simonmar]: > That Haddock bug only applies to references to modules from inside documentation, so the hyperlinks for the actual names should still work, right? Yes. I was trying to say "Look in GHC.Arr for docs". > Also, could we do something like this: > > {{{ > module Data.Array where > import qualified GHC.Arr > > -- | .. documentation for 'array' > array = GHC.Arr.array > }}} > > only works for functions, of course. Also, if GHC.Arr.array and Data.Array.array are both in scope then you have an ambiguous variable. But links to array in the docs go to GHC.Arr now, so it's only people browsing to the Data.Array docs who will have the inconvenience of having to manually browse to the GHC.Arr docs. It's not a perfect situation, but I think it's good enough for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 18:48:50 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 18:44:50 2008 Subject: [GHC] #2657: DPH Haddock document isn't linked from Libraries document In-Reply-To: <047.3ea7891160068f161ef63cd3e40d298b@localhost> References: <047.3ea7891160068f161ef63cd3e40d298b@localhost> Message-ID: <056.d191977f7963eea97cda88be1ea6cd71@localhost> #2657: DPH Haddock document isn't linked from Libraries document ------------------------------+--------------------------------------------- Reporter: shelarcy | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 14 19:28:11 2008 From: trac at galois.com (GHC) Date: Tue Oct 14 19:24:10 2008 Subject: [GHC] #2657: DPH Haddock document isn't linked from Libraries document In-Reply-To: <047.3ea7891160068f161ef63cd3e40d298b@localhost> References: <047.3ea7891160068f161ef63cd3e40d298b@localhost> Message-ID: <056.5cf771d24c5a930d3bc7a02f9cd93b07@localhost> #2657: DPH Haddock document isn't linked from Libraries document ------------------------------+--------------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: igloo => * cc: david.waern@gmail.com (added) Comment: Fixing this is easy in theory, it's just: {{{ hunk ./libraries/gen_contents_index 12 + if [ -d dph ] + then + HADDOCK_FILES="$HADDOCK_FILES `ls -1 dph/*/dist/doc/html/*/*.haddock | sort`" + fi hunk ./libraries/gen_contents_index 26 - NAME=`echo "$HADDOCK_FILE" | sed 's#/.*##'` + NAME=`echo "$HADDOCK_FILE" | sed 's#/dist/.*##' | sed 's#.*/##' ` }}} Unfortunately, life is never that simple. The dph packages have a number of "Other" (as opposed to "Exposed") modules. When haddocking those, Cabal passes `--hide=Data.Array.Parallel.Stream.Flat` etc to haddock, so no docs get generated. However, the script that calls haddock to make the index doesn't know about "Other" modules, so it doesn't pass them to haddock, and they get put in the contents page. Haddock manages to not put the "Other" modules in the package-specific index, so presumably it's just a matter of recording that the module is hidden in the haddock interface file. David, is this easy to fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 03:59:15 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 03:55:18 2008 Subject: [GHC] #2697: bad testsuite results with ghc-6.10.0.20081007 Message-ID: <045.c368cc178489a6d371c14b6319d3b743@localhost> #2697: bad testsuite results with ghc-6.10.0.20081007 ---------------------------------+------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ As I've mailed {{{ My testsuite results can be found under: http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.10.0.20081007-tests.log.bz2 http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc- solaris/ghcs/ghc-6.10.0.20081007-tests.log.bz2 371 unexpected failures resp. 195 unexpected failures }}} These are far too many failures, I think. I've only called "make" in ghc-regress. The results do not only depend on the build-tree but at least on the user's package.conf file. Would someone care to look through the logs? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 04:29:51 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 04:25:54 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.e49592b57d6af87d7b6b69d213bb8d00@localhost> #1876: Complete shared library support ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by clemens): * status: new => assigned * owner: => clemens * cc: clemens@endorphin.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 04:36:02 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 04:32:00 2008 Subject: [GHC] #2651: BlockedIndefinitely not thrown when it should be In-Reply-To: <047.e9da191bb9568ef4d909376b59b9027c@localhost> References: <047.e9da191bb9568ef4d909376b59b9027c@localhost> Message-ID: <056.7f11604140dec1f67d860bada3eee7a0@localhost> #2651: BlockedIndefinitely not thrown when it should be ------------------------------+--------------------------------------------- Reporter: govereau | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: As Ian says, it works with the threaded RTS. This is because detecting deadlocked threads requires the GC to run, and only the threaded RTS runs the GC during idle time (i.e. when the main thread is in `threadDelay` in this example). The non-threaded RTS just sits in `select()` waiting for the time to expire. I suppose it could notice that it had a long time to wait and do a GC, but I don't feel terribly inclined to fix this since there's an easy workaround. We don't guarantee anything about deadlock detection anyway, because GC can always be delayed for an arbitrary amount of time, so it's really just a debugging feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 04:37:37 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 04:33:35 2008 Subject: [GHC] #2694: Building GHC 6.10 with Cabal 1.6 fails due to in-tree Cabal 1.5.5 In-Reply-To: <043.74586645854c8ad208c6aecff658335f@localhost> References: <043.74586645854c8ad208c6aecff658335f@localhost> Message-ID: <052.600d4b940f8561338f1f95ce98dae573@localhost> #2694: Building GHC 6.10 with Cabal 1.6 fails due to in-tree Cabal 1.5.5 ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 05:03:09 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 04:59:08 2008 Subject: [GHC] #2696: forall not recognized in RULES In-Reply-To: <044.12be41e0f2e44b9a71e12eafba7f0064@localhost> References: <044.12be41e0f2e44b9a71e12eafba7f0064@localhost> Message-ID: <053.99ff800b76e08bae3b656bd1d063110d@localhost> #2696: forall not recognized in RULES ------------------------------+--------------------------------------------- Reporter: conal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Fixed by {{{ Wed Oct 15 09:43:44 BST 2008 simonpj@microsoft.com * Fix Trac #2497; two separate typos in Lexer.x }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 05:03:44 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 04:59:43 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.3695150720546b03330e8ed89c357ccb@localhost> #2497: Weird scoping for tyvars in rules --------------------------------------------+------------------------------- Reporter: rl | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2497 | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by simonpj): * status: reopened => new * owner: => igloo * type: bug => merge Comment: Finally fixed by {{{ Wed Oct 15 09:43:44 BST 2008 simonpj@microsoft.com * Fix Trac #2497; two separate typos in Lexer.x }}} Please merge to 6.10 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 05:36:14 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 05:32:17 2008 Subject: [GHC] #2698: Windows binary distribution pops up README.TXT for the source distribution Message-ID: <045.bc598ef2cae0aae707dbc598e8bfe53c@localhost> #2698: Windows binary distribution pops up README.TXT for the source distribution -----------------------+---------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- When the Windows installer finishes, it offers to show you a README. The first sentence of this is "This is the source tree for GHC,..." and it goes on to discuss how to get the source and build it. This is a bit confusing for a binary distribution. I'd suggest leaving it out altogether if no alternative readme targetted at binary distributions exists. This is with 6.10.1 RC1 (http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/ghc-6.10.0.20081007-i386 -unknown-mingw32.exe) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 08:33:40 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 08:29:36 2008 Subject: [GHC] #2699: broken pipe errors are too noisy Message-ID: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The following program {{{ main = mapM_ print fibs where fibs = 0 : 1 : zipWith (+) fibs (tail fibs) }}} produces this output when piped through {{{head}}} on a shell: {{{ # ./a.out | head -n 1 0 a.out: : commitAndReleaseBuffer: resource vanished (Broken pipe) # }}} The final error message is annoying. It would be nice if the RTS suppressed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 08:41:08 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 08:37:05 2008 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.411cc4fa012ce0951f0c5bf78b105935@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by int-e): This is related to #1619 where the silent abortion in the case of broken pipes got turned into an exception. It's not quite clear which exception should be silenced. EPIPE becomes an {{{IOError}}} with type {{{ResourceVanished}}}, but that also includes several other error conditions, like {{{E_CONNRES}}}. The original {{{errno}}} number is not contained in {{{IOError}}}; all that's left is the corresponding value of {{{strerr()}}}, in the {{{ioe_description}}} field. Can we get away with filtering {{{IOError { ioe_type = ResourceVanished, ioe_filename = Just "" } }}}? It's a hack though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 08:55:30 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 08:51:32 2008 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.3c93406c5ea158171447cc7e0805820f@localhost> #2615: ghci doesn't play nice with linker scripts --------------------------+------------------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by maeder): * cc: maeder (added) * architecture: x86_64 (amd64) => Unknown/Multiple Comment: here is another example using ghc-6.8.3 {{{ Loading package cairo-0.9.13 ... can't load .so/.DLL for: pthread (/usr/lib/libpthread.so: invalid ELF header) }}} /usr/lib/libpthread.so contains: {{{ /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 10:54:28 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 10:50:27 2008 Subject: [GHC] #2651: BlockedIndefinitely not thrown when it should be In-Reply-To: <047.e9da191bb9568ef4d909376b59b9027c@localhost> References: <047.e9da191bb9568ef4d909376b59b9027c@localhost> Message-ID: <056.dfa1cda13be37a5ba61cd300b14e4a10@localhost> #2651: BlockedIndefinitely not thrown when it should be ------------------------------+--------------------------------------------- Reporter: govereau | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by govereau): Just to be clear. I observed this problem with the threaded RTS on OSX and only with the STM-like example, not MVars. I am happy to hear that it is fixed in 6.10! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 13:04:28 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 13:00:26 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.875406d0401ae5d18c53ca63c1c30723@localhost> #2497: Weird scoping for tyvars in rules --------------------------------------------+------------------------------- Reporter: rl | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2497 | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 13:40:54 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 13:37:01 2008 Subject: [GHC] #2680: Type-checking performance regression In-Reply-To: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> References: <044.fdcd5408109d617ebbb48294cca73ee8@localhost> Message-ID: <053.be5a4ff3d6d5b541f162e7b79b2a70bd@localhost> #2680: Type-checking performance regression ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: compile-time performance bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 13:41:24 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 13:37:26 2008 Subject: [GHC] #2687: Lexical error when compiling unicode-prelude-0.1 using GHC 6.10.1 RC1 In-Reply-To: <049.bc4576b09ee6219e664f054b11cec9bf@localhost> References: <049.bc4576b09ee6219e664f054b11cec9bf@localhost> Message-ID: <058.1a7de1f2629e88bc74b8b8f4f6506412@localhost> #2687: Lexical error when compiling unicode-prelude-0.1 using GHC 6.10.1 RC1 ------------------------+--------------------------------------------------- Reporter: albertfong | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ------------------------+--------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: No objections, so I've done as Simon suggested in HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 15:58:36 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 15:54:39 2008 Subject: [GHC] #2694: Building GHC 6.10 with Cabal 1.6 fails due to in-tree Cabal 1.5.5 In-Reply-To: <043.74586645854c8ad208c6aecff658335f@localhost> References: <043.74586645854c8ad208c6aecff658335f@localhost> Message-ID: <052.8314651d175e08fd96cc3f04f3dcf630@localhost> #2694: Building GHC 6.10 with Cabal 1.6 fails due to in-tree Cabal 1.5.5 ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: The build system now forcibly uses the in-tree Cabal version (in HEAD and 6.10). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 16:37:32 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 16:33:29 2008 Subject: [GHC] #2690: Problem building HEAD when a newer version of Cabal is installed In-Reply-To: <044.893bccd6d8cd2bab0e7f1334217c55e7@localhost> References: <044.893bccd6d8cd2bab0e7f1334217c55e7@localhost> Message-ID: <053.e915b107fd31f6389e6d422a0ebef488@localhost> #2690: Problem building HEAD when a newer version of Cabal is installed ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed * milestone: => 6.10.1 Comment: Thanks for the report; fixed in HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 16:38:24 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 16:34:34 2008 Subject: [GHC] #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown-linux-libedit2 In-Reply-To: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> References: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> Message-ID: <054.0123f348c9731e4a4590c60fb25366c0@localhost> #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown- linux-libedit2 ----------------------+----------------------------------------------------- Reporter: dancor | Owner: judah Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > ~ stty stop '' > ~ # ^S prints literal ^S > ~ cat a.hs > main = return () > ~ ghc --make a.hs > ~ ./a > ~ # ^S still prints literal ^S > ~ runghc a.hs > ~ # but now, ^S sends XOFF to terminal > > Happens in console/xterm/urxvt and in/not-in gnu screen. > Haven't seen this in any previous versions of ghc. > > ~ uname -a > Linux pima 2.6.25-2-686 #1 SMP Fri Jul 18 17:46:56 UTC 2008 i686 > GNU/Linux > ~ # debian lenny New description: {{{ ~ stty stop '' ~ # ^S prints literal ^S ~ cat a.hs main = return () ~ ghc --make a.hs ~ ./a ~ # ^S still prints literal ^S ~ runghc a.hs ~ # but now, ^S sends XOFF to terminal }}} Happens in console/xterm/urxvt and in/not-in gnu screen. Haven't seen this in any previous versions of ghc. {{{ ~ uname -a Linux pima 2.6.25-2-686 #1 SMP Fri Jul 18 17:46:56 UTC 2008 i686 GNU/Linux ~ # debian lenny }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 16:41:35 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 16:37:36 2008 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.6c00c52f3021e42955048fa7dc72b39a@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 16:40:02 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 16:38:28 2008 Subject: [GHC] #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown-linux-libedit2 In-Reply-To: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> References: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> Message-ID: <054.474cca0daee18a17b28334173755450f@localhost> #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown- linux-libedit2 ----------------------+----------------------------------------------------- Reporter: dancor | Owner: judah Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 16:43:08 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 16:39:05 2008 Subject: [GHC] #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 In-Reply-To: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> References: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> Message-ID: <058.ccbe0bb0d6fa27c982699a2123e3a885@localhost> #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 ------------------------+--------------------------------------------------- Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: panic | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------+--------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > The following file (DM.hs) panics GHC 6.10 with this error message: > > c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ > c:\ghc\ghc-6.10.0.20081007\bin\ghc.exe ~/DM.hs > ghc.exe: panic! (the 'impossible' happened) > (GHC version 6.10.0.20081007 for i386-unknown-mingw32): > TcTyFuns.uMeta: normalisation shouldn't allow x ~ x > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > --Ben > > ---- DM.hs ---- > {-# LANGUAGE GADTs, TypeFamilies #-} > > type family TFn a :: * > > data PVR a = PVR {pvrX :: Int} deriving (Eq) > > f :: () -> Maybe (TFn a) > f _ = undefined > > g :: Maybe () > g = do > pvs <- mapM f undefined > > let n = (map pvrX pvs) `min` (map pvrX pvs) > > undefined > ---- DM.hs ---- > > Other info: > > c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ > c:\ghc\ghc-6.10.0.20081007\bin\ghc-pkg.exe list > c:/ghc/ghc-6.10.0.20081007\package.conf: > Cabal-1.5.5, HUnit-1.2.0.0, QuickCheck-1.1.0.0, Win32-2.2.0.0, > array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, bytestring-0.9.1.4, > containers-0.2.0.0, directory-1.0.0.2, (dph-base-0.3), > (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), > (dph-prim-seq-0.3), (dph-seq-0.3), filepath-1.1.0.1, > (ghc-6.10.0.20081007), ghc-prim-0.1.0.0, haddock-2.2.2, > haskell-src-1.0.1.2, haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.1, > integer-0.1.0.0, mtl-1.1.0.1, network-2.2.0.0, old-locale-1.0.0.1, > old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.0.0.1, > parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1, > regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, > rts-1.0, stm-2.1.1.1, (syb-0.1.0.0), template-haskell-2.3.0.0, > time-1.1.2.1, xhtml-3000.2.0.1 > > c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ > c:\ghc\ghc-6.10.0.20081007\bin\ghc.exe -v > Glasgow Haskell Compiler, Version 6.10.0.20081007, for Haskell 98, stage > 2 booted by GHC version 6.8.3 > Using package config file: C:\ghc\ghc-6.10.0.20081007\package.conf > hiding package base-3.0.3.0 to avoid conflict with later version > base-4.0.0.0 > wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 > wired-in package integer mapped to integer-0.1.0.0 > wired-in package base mapped to base-4.0.0.0 > wired-in package rts mapped to rts-1.0 > wired-in package haskell98 mapped to haskell98-1.0.1.0 > wired-in package syb mapped to syb-0.1.0.0 > wired-in package template-haskell mapped to template-haskell-2.3.0.0 > wired-in package dph-seq mapped to dph-seq-0.3 > wired-in package dph-par mapped to dph-par-0.3 > Hsc static flags: -static > *** Deleting temp files: > Deleting: > *** Deleting temp dirs: > Deleting: > ghc.exe: no input files > Usage: For basic information, try the `--help' option. New description: The following file (DM.hs) panics GHC 6.10 with this error message: {{{ c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ c:\ghc\ghc-6.10.0.20081007\bin\ghc.exe ~/DM.hs ghc.exe: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for i386-unknown-mingw32): TcTyFuns.uMeta: normalisation shouldn't allow x ~ x Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} --Ben DM.hs: {{{ {-# LANGUAGE GADTs, TypeFamilies #-} type family TFn a :: * data PVR a = PVR {pvrX :: Int} deriving (Eq) f :: () -> Maybe (TFn a) f _ = undefined g :: Maybe () g = do pvs <- mapM f undefined let n = (map pvrX pvs) `min` (map pvrX pvs) undefined }}} Other info: {{{ c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ c:\ghc\ghc-6.10.0.20081007\bin\ghc-pkg.exe list c:/ghc/ghc-6.10.0.20081007\package.conf: Cabal-1.5.5, HUnit-1.2.0.0, QuickCheck-1.1.0.0, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, bytestring-0.9.1.4, containers-0.2.0.0, directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), filepath-1.1.0.1, (ghc-6.10.0.20081007), ghc-prim-0.1.0.0, haddock-2.2.2, haskell-src-1.0.1.2, haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.1, integer-0.1.0.0, mtl-1.1.0.1, network-2.2.0.0, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.0.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.1, (syb-0.1.0.0), template-haskell-2.3.0.0, time-1.1.2.1, xhtml-3000.2.0.1 c:/ws/main/depot/QA/EDG/EDG_priv/FPF_Dev.br/src $ c:\ghc\ghc-6.10.0.20081007\bin\ghc.exe -v Glasgow Haskell Compiler, Version 6.10.0.20081007, for Haskell 98, stage 2 booted by GHC version 6.8.3 Using package config file: C:\ghc\ghc-6.10.0.20081007\package.conf hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.0 wired-in package base mapped to base-4.0.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.0 wired-in package template-haskell mapped to template-haskell-2.3.0.0 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc.exe: no input files Usage: For basic information, try the `--help' option. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 18:13:28 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 18:09:28 2008 Subject: [GHC] #2697: bad testsuite results with ghc-6.10.0.20081007 In-Reply-To: <045.c368cc178489a6d371c14b6319d3b743@localhost> References: <045.c368cc178489a6d371c14b6319d3b743@localhost> Message-ID: <054.98fa2f26377c47d7e17a5c0ab28a2b66@localhost> #2697: bad testsuite results with ghc-6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 18:13:49 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 18:09:50 2008 Subject: [GHC] #2698: Windows binary distribution pops up README.TXT for the source distribution In-Reply-To: <045.bc598ef2cae0aae707dbc598e8bfe53c@localhost> References: <045.bc598ef2cae0aae707dbc598e8bfe53c@localhost> Message-ID: <054.c1504ff54d6e1f3a2c8d8ad7318d6936@localhost> #2698: Windows binary distribution pops up README.TXT for the source distribution ----------------------+----------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 18:15:56 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 18:11:52 2008 Subject: [GHC] #2700: Template Haskell pretty printer arrow always associates right Message-ID: <047.b71a33f0f71e965d047800e7daaf440d@localhost> #2700: Template Haskell pretty printer arrow always associates right ------------------------------------------------+--------------------------- Reporter: aprocter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: critical Keywords: th pprint pretty print template | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ------------------------------------------------+--------------------------- When I run a Template Haskell-generated tysig declaration through pprint, the associativity for -> comes out incorrectly, e.g.: sigD (mkName "foo") [t|(Int -> Bool) -> Bool|] renders as: foo :: GHC.Base.Int -> GHC.Base.Bool -> GHC.Base.Bool (note that it's dropping the parens, associating right instead of left) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 18:18:10 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 18:14:05 2008 Subject: [GHC] #2700: Template Haskell pretty printer arrow always associates right In-Reply-To: <047.b71a33f0f71e965d047800e7daaf440d@localhost> References: <047.b71a33f0f71e965d047800e7daaf440d@localhost> Message-ID: <056.2e91a992858fef69af93f102f14ee438@localhost> #2700: Template Haskell pretty printer arrow always associates right ------------------------------------------------+--------------------------- Reporter: aprocter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: critical | Resolution: Keywords: th pprint pretty print template | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ------------------------------------------------+--------------------------- Comment (by aprocter): Run "ghc --make TestPPrint.hs" to see the incorrect output on stdout. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 15 23:19:08 2008 From: trac at galois.com (GHC) Date: Wed Oct 15 23:17:00 2008 Subject: [GHC] #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown-linux-libedit2 In-Reply-To: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> References: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> Message-ID: <054.7d6baa0a163c91e984c19cf911840b77@localhost> #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown- linux-libedit2 ----------------------+----------------------------------------------------- Reporter: dancor | Owner: judah Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by judah): I've confirmed this behavior to be a bug in libedit. I'm still attempting to track down the exact cause (and fix) of the bug, but in the meantime I've submitted a workaround patch to cvs-ghc: {{{ Wed Oct 15 19:48:38 PDT 2008 Judah Jacobson * FIX #2691: Manually reset the terminal to its initial settings; works around a bug in libedit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 03:56:31 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 03:52:25 2008 Subject: [GHC] #2684: Stack overflow in stream-fusion library with GHC 6.10 RC In-Reply-To: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> References: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> Message-ID: <052.7e5642858ab4b39484f9f4bbe0bc1fa9@localhost> #2684: Stack overflow in stream-fusion library with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonpj): I know more or less what is happening now. Here's the diagnosis. Stream.2.hs contains this: {{{ mapx f (x:xs) = f x : mapx f xs {-# NOINLINE [1] mapx #-} {-# RULES "mapx -> fusible" [~1] forall f xs. mapx f xs = unstream (mapy f (stream xs)) "mapx -> unfused" [1] forall f xs. unstream (mapy f (stream xs)) = mapx f xs #-} }}} (Note that the second of these rules is an orphan.) After applying the `fusible` rule, at the end of Phase 1 GHC sees {{{ mapx f (x:xs) = f x : unstream (mapy f (stream xs)) }}} Now `mapx` looks non-recursive; after all, `mapy` is imported. So when the occurrence analyser runs in Phase 0 `mapx` is not marked as a loop breaker and can be inlined freely. However the `unfused` rule fires, and makes `mapx` recursive after all. Before the occurrence analyser runs again, though, the simplifier processes the next definition: {{{ initsx (x:xs) = [] : mapx (x:) (initsx xs) }}} Since `mapx` is not a loop breaker, it's just inlined repeatedly; result infinite loop. You may say that the occurrence analyser should be run again ''after'' finishing each definition. But that is only sticking plaster. Suppose we had {{{ mapx x = mapy x }}} (non-recursive, no rules) and imported that into a scope where there was an orphan rule {{{ RULES "x" mapy = mapx }}} Then you can see that would make GHC loop. (Inline `mapx`, run the RULE, and repeat.) What to do? In general it's very hard to do much about RULES that give rise to loops, esp when they are orphans. When they are defined in the same module as the function they are RULES for, GHC is pretty good; but otherwise it's difficult. In this case the obvious thing is to add {{{ {-# NOINLINE [~1] mapx #-} }}} to stop it being inlined after Phase 1. That should cure the loop, but I'm not sure if the optimisations you have in mind would still work. (Curiously the exact inverse annotation is provided in the test case, saying don't inline ''until'' Phase 1.) I'm surprised 6.8.3 works on this example; I suspect it's a fluke. (Should check this.) Bottom line: I can't see a quick fix. Need to discuss how important this pattern is. At least we know what the problem is. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 05:16:52 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 05:12:47 2008 Subject: [GHC] #2651: BlockedIndefinitely not thrown when it should be In-Reply-To: <047.e9da191bb9568ef4d909376b59b9027c@localhost> References: <047.e9da191bb9568ef4d909376b59b9027c@localhost> Message-ID: <056.d8e2e8343d62bc3fc1091468c07e8b97@localhost> #2651: BlockedIndefinitely not thrown when it should be ------------------------------+--------------------------------------------- Reporter: govereau | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Replying to [comment:3 govereau]: > Just to be clear. I observed this problem with the threaded RTS on OSX and only with the STM-like example, not MVars. I am happy to hear that it is fixed in 6.10! Thanks! A thread created by 'forkIO' has an exception handler that ignores 'BlockedIndefintely', so that is why it isn't printed. It is still being raised, however. I've just added a note about this to the documentation for 'forkIO'. Just to be clear, nothing has changed in 6.10.1 here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 06:53:03 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 06:48:58 2008 Subject: [GHC] #2684: Stack overflow in stream-fusion library with GHC 6.10 RC In-Reply-To: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> References: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> Message-ID: <052.fdf83faaaac31a16494798975ed80dc8@localhost> #2684: Stack overflow in stream-fusion library with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by rl): FWIW, I don't think it is necessary to do anything about this. The library code and the pattern in general are arguably wrong since the `fusible` rule really shouldn't be applied in the rhs of `mapx`. It is also easily fixed: {{{ mapx = id mapz mapz f (x:xs) = f x : mapz f xs {-# INLINE [1] mapx #-} {-# RULES "mapx -> fusible" [~1] forall f xs. mapx f xs = unstream (mapy f (stream xs)) "mapx -> unfused" [1] forall f xs. unstream (mapy f (stream xs)) = mapz f xs #-} }}} or simply {{{ mapx f xs = unstream (mapy f (stream xs)) mapz f (x:xs) = f x : mapz f xs {-# INLINE mapx #-} {-# RULES "mapx -> unfused" [1] forall f xs. unstream (mapy f (stream xs)) = mapz f xs #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 06:54:21 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 06:50:14 2008 Subject: [GHC] #2683: Regression with 6.10: panic in xmonad-contrib In-Reply-To: <043.cf6c9356908d84d15cb72785d970ada9@localhost> References: <043.cf6c9356908d84d15cb72785d970ada9@localhost> Message-ID: <052.092aa7fe0f4d31d5d22b0f0cdef3435d@localhost> #2683: Regression with 6.10: panic in xmonad-contrib ----------------------+----------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by simonpj): The assertion is to do with "boxy types" which Dimitrios and I are about (well, over the next few months) to overhaul completely. Can you see if matters are ok without DEBUG on? I bet they will be, and the ASSERT is over-cautious. In which case, we'll let it ride for now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 06:56:09 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 06:52:03 2008 Subject: [GHC] #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib In-Reply-To: <043.cf6c9356908d84d15cb72785d970ada9@localhost> References: <043.cf6c9356908d84d15cb72785d970ada9@localhost> Message-ID: <052.c12a93b4512a57777e681781f72d96d2@localhost> #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib ----------------------+----------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * summary: Regression with 6.10: panic in xmonad-contrib => Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 06:58:44 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 06:54:38 2008 Subject: [GHC] #2684: Stack overflow in stream-fusion library with GHC 6.10 RC In-Reply-To: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> References: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> Message-ID: <052.bc144e524a563d59b3a7d4ba06cf8566@localhost> #2684: Stack overflow in stream-fusion library with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonpj): Excellent. So who is responsible for the library `stream-fusion`? Can he or she take advantage of Roman's advice? Meanwhile I'd like to leave this ticket open, to remind someone (ideally not me) to add some Wiki docs to [http://haskell.org/haskellwiki/GHC/Using_rules] to explain in a more standalone way what I documented above. Pretty please? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 07:07:31 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 07:03:25 2008 Subject: [GHC] #2701: Cannot derive Data for structures containing unboxed values Message-ID: <053.4e805d871d5b4c042cff7a15f7231353@localhost> #2701: Cannot derive Data for structures containing unboxed values ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Trying to compile this: {{{ {-# LANGUAGE MagicHash, DeriveDataTypeable #-} module Test where import GHC.Prim import Data.Data import Data.Typeable data Foo = MkFoo Int# deriving (Typeable, Data) }}} Results in an error: {{{ $ ghc/stage1-inplace/ghc --make ~/DerivingUnboxed.hs [1 of 1] Compiling Test ( /Users/mbolingbroke/DerivingUnboxed.hs, /Users/mbolingbroke/DerivingUnboxed.o ) /Users/mbolingbroke/DerivingUnboxed.hs:10:29: Couldn't match kind `#' against `*' When matching the kinds of `Int# :: #' and `d :: *' Expected type: d Inferred type: Int# In the first argument of `z', namely `MkFoo' /Users/mbolingbroke/DerivingUnboxed.hs:10:29: Couldn't match kind `#' against `*' When matching the kinds of `Int# :: #' and `b :: *' Expected type: b Inferred type: Int# In the first argument of `z', namely `MkFoo' }}} I'm not sure if this is really a bug or not. It might be nice if deriving Data handled this case by reboxing Int#, or alternatively if it gave a clear error messages about not being able to handle unboxed values. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 11:41:35 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 11:37:32 2008 Subject: [GHC] #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 In-Reply-To: <059.9ba98474c2b63eccc55349ae913ba846@localhost> References: <059.9ba98474c2b63eccc55349ae913ba846@localhost> Message-ID: <068.0cc0417edef0ed3ea384aec79160db8e@localhost> #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 ----------------------------------+----------------------------------------- Reporter: kahl@cas.mcmaster.ca | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: normal build | Architecture: powerpc64 Os: Linux | ----------------------------------+----------------------------------------- Comment (by wkahl): For ghc-6.10.0.20081007 on ppc64 with 32-bit userland, {{{linux32}}} is still necessary. Here I get: {{{ $ uname -m ppc64 $ gcc -dumpmachine powerpc-unknown-linux-gnu }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 13:26:07 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 13:22:01 2008 Subject: [GHC] #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib In-Reply-To: <043.cf6c9356908d84d15cb72785d970ada9@localhost> References: <043.cf6c9356908d84d15cb72785d970ada9@localhost> Message-ID: <052.7a7793c6b2b947888b7b0e2654007953@localhost> #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib ----------------------+----------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by dons): @simon xmonad-contrib builds ok without the DEBUG compiler, so might be ok to let it ride. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 14:31:19 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 14:27:13 2008 Subject: [GHC] #2684: Stack overflow in stream-fusion library with GHC 6.10 RC In-Reply-To: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> References: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> Message-ID: <052.75f742b66ba801aedae4276d18092d0f@localhost> #2684: Stack overflow in stream-fusion library with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by dons): @simonpj He/she is me, and yes, I'll apply Roman's advice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 15:04:15 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 15:00:10 2008 Subject: [GHC] #2702: having build issues with ghc 6.6.1 Message-ID: <047.9af5f2bef03f66c96c590fff08693d38@localhost> #2702: having build issues with ghc 6.6.1 -------------------------+-------------------------------------------------- Reporter: wnyrodeo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.6.1 | Severity: critical Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Hi, I am very new to building ghc. My platform is "i686-pc-linux-gnu", my system is suse linux enterprise server 9 32-bit, and my system does not have ghc preinstalled. that's why I thought that I have to port/build ghc for my platform as an unregistered build. I created the build.mk file as follows and put that in my mk/build.mk in the source tree that I have downloaded. SRC_HC_OPTS = -H32m -O -fasm -Rghc-timing GhcStage1HcOpts = -O0 -DDEBUG -W GhcLibHcOpts = -O0 -fgenerics GhcLibWays = SplitObjs = NO I am using gcc 3.4.2. My configure command is as follows (not sure if I am doing anything wrong here, I have tried to follow the build/port instructions as closley as I could: ./configure --prefix=/opt/ghc --with-gcc=/opt/gcc/3.4.2/bin/gcc --enable- hc-boot --enable-hc-boot-unregisterised configure seems to run ok. when I go about building, thats when I get the following error: gmake[1]: *** No rule to make target `Apply.o', needed by `libHSrts.a'. Stop. Please help me with this. I open for anything to try out to get this done. Thanks in advance! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 15:07:04 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 15:02:58 2008 Subject: [GHC] #2702: having build issues with ghc 6.6.1 In-Reply-To: <047.9af5f2bef03f66c96c590fff08693d38@localhost> References: <047.9af5f2bef03f66c96c590fff08693d38@localhost> Message-ID: <056.7697fbba727a79bfc67bee23d6d3aa1d@localhost> #2702: having build issues with ghc 6.6.1 -------------------------+-------------------------------------------------- Reporter: wnyrodeo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: critical | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by wnyrodeo): * cc: imam.toufique@intel.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 16:43:23 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 16:39:19 2008 Subject: [GHC] #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior In-Reply-To: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> References: <043.7879ff2ec970e5670b4c9255c0e07b58@localhost> Message-ID: <052.93fe7072061b60cbe5dd0f973be62ef8@localhost> #2638: runInteractiveCommand on Win32 leaks, produces inconsistent behavior -------------------------------+-------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/process | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: vax Os: Windows | -------------------------------+-------------------------------------------- Comment (by sclv): I understand the motivation for leaving the issue with `terminateProcess` as is. However, given that this behavior can be irritating/confusing, it would be appropriate to add documentation to the Haddock of `runInteractiveCommand` or however it is presented in the new `System.Process` API. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 17:10:48 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 17:06:41 2008 Subject: [GHC] #2703: Buffer overflow, occasional segfaults when using handles created by Network. Message-ID: <043.0b636667312adf746bdfc543d5231d22@localhost> #2703: Buffer overflow, occasional segfaults when using handles created by Network. -------------------------------+-------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- See attached test cases (BigSock and BigSockFail). They both implement a simple echo server that reads lines from a socket and writes them to stdout -- the working case using the underlying Network.Socket API and the failing case using handles from the Network library. If a single line of sufficient size (We used a 5MB file, but a smaller one would probably be fine) is sent to the working case, it behaves as expected, eventually writing out the line. Additional connections may be made during this, which write data to stdout as expected. Additional connections may also be made following this. If a line of the same size is sent to the failing case, it occasionally segfaults, although this is hard to reproduce. When it does not segfault, the socket nonetheless becomes permanently nonresponsive. The large line is never output. Future connections are accepted by the binary (i.e. netcat reveals they are accepted), but the accept call in Haskell never succeeds, and no further interaction with the binary over the socket is possible. This behavior has caused some massive grief before the cause was tracked down. Both cases have been tested with the threaded runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 19:54:27 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 19:50:53 2008 Subject: [GHC] #2704: "403 Forbidden" on recent 6.10.0 snapshot tarballs Message-ID: <045.f66631efa340d18e5e794d3248ba9c50@localhost> #2704: "403 Forbidden" on recent 6.10.0 snapshot tarballs ---------------------------------+------------------------------------------ Reporter: ingmar | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ On all 3 snapshot distributions since 20081014 @ http://www.haskell.org/ghc/dist/stable/dist/ I get "403 Forbidden" errors. This seems to be the same issue as in ticket:1142. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 20:52:58 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 20:48:51 2008 Subject: [GHC] #2705: ghc does not report haskell98's version number. Message-ID: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> #2705: ghc does not report haskell98's version number. ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ If you invoke ghc with something like -hide-all-packages and then run it over a file like so: {{{ import Prelude import System.Process main = putStrLn "hi" }}} GHC will tell you: {{{ $ ghc -hide-all-packages test1.hs test2.hs:1:0: Failed to load interface for `Prelude': it is a member of package base-3.0.3.0, which is hidden }}} But if you have a file like this which uses haskell98 {{{ module Main where import System import Prelude main = do p <- getProgName putStrLn $ "program name is " ++ p }}} And try to compile it, GHC says this: {{{ $ ghc -hide-all-packages test2.hs Main.hs:2:0: Failed to load interface for `System': it is a member of package haskell98, which is hidden }}} It does not report the version number of haskell98. There is a reason we want this: while hacking on David Roundy's build system franchise (darcs get http://darcs.net/repos/franchise/) I noticed that while the package built under GHC 6.10 (with a tweak or two,) it reported the franchise package as broken. However, when running ghc-pkg check I got this (very unhelpful) output: {{{ $ ghc-pkg list franchise /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.0.20081007/./package.conf: /Users/austinseipp/.ghc/i386-darwin-6.10.0.20081007/package.conf: {franchise-0.0.3} $ ghc-pkg check package franchise-0.0.3 has missing dependencies: $ }}} This is the configuration file generated by franchise, for itself: {{{ name: franchise version: 0.0.3 license: BSD3 copyright: David Roundy maintainer: ??? import-dirs: "/Users/austinseipp/lib/franchise-0.0.3/" library-dirs: "/Users/austinseipp/lib/franchise-0.0.3/" exposed-modules: Distribution.Franchise hidden-modules: Distribution.Franchise.StringSet Distribution.Franchise.ConfigureState Distribution.Franchise.Util Distribution.Franchise.Buildable Distribution.Franchise.Ghc hs-libraries: franchise exposed: True depends: haskell98, base-3.0.3.0, directory-1.0.0.2, process-1.0.1.0 }}} The problem is: {{{ depends: haskell98, base-3.0.3.0, directory-1.0.0.2, process-1.0.1.0 }}} Should be: {{{ depends: haskell98-1.0.1.0, base-3.0.3.0, directory-1.0.0.2, process-1.0.1.0 }}} I tracked this down further by examining the source code; it seems as if franchise starts off by running 'ghc -hide-all-packages' over the source code repeatedly, gobbling up and parsing all of the 'package is hidden' errors until there are no more, and determining what packages are necessary and what version and using that as build info. But as GHC does not report the version number of haskell98, it simply emits 'depends: haskell98' and ghc-pkg reports it as broken! Using a version of franchise with a patch of mine to show some debugging output, we can see this is the problem: {{{ $ runghc Setup.hs configure Configuring... "\nDistribution/Franchise/ConfigureState.hs:66:7:\n Could not find module `Maybe':\n it is a member of package haskell98, which is hidden\n" adding ["haskell98"] "\nDistribution/Franchise/ConfigureState.hs:63:7:\n Could not find module `System.Console.GetOpt':\n it is a member of package base-3.0.3.0, which is hidden\n" adding ["base-3.0.3.0"] "\nDistribution/Franchise/ConfigureState.hs:60:7:\n Could not find module `System.Directory':\n it is a member of package directory-1.0.0.2, which is hidden\n" adding ["directory-1.0.0.2"] "\nDistribution/Franchise/Util.hs:46:7:\n Could not find module `System.Process':\n it is a member of package process-1.0.1.0, which is hidden\n" adding ["process-1.0.1.0"] Added packages haskell98 base-3.0.3.0 directory-1.0.0.2 process-1.0.1.0... Configure successful. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 20:56:40 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 20:52:32 2008 Subject: [GHC] #2705: ghc does not report haskell98's version number. In-Reply-To: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> References: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> Message-ID: <061.e1a8142e46cade3da4cf1d822f111770@localhost> #2705: ghc does not report haskell98's version number. ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by thoughtpolice): I'll also mention that while this happens, we will likely have to resort to simply checking if there is no version tag, and if not, checking ghc- pkg output and finding the proper package version to use and emit that the configuration file we register with ghc-pkg. It also means that until we implement this or this gets fixed, any library built with franchise that depends on haskell98 will be reported as broken by ghc-pkg (although it really probably isn't, and ghc-pkg check will be of no help.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 21:10:23 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 21:06:16 2008 Subject: [GHC] #2705: ghc does not report haskell98's version number. In-Reply-To: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> References: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> Message-ID: <061.2be59621ab3d4d11714a1d2dd08c385f@localhost> #2705: ghc does not report haskell98's version number. ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by duncan): Parsing ghc's error messages seems like a "Bad Idea"tm. A better approach would be to steal the code out of hmake and chase import dependencies then use the information from ghc-pkg dump to map that back to package names. I wonder how the package is actually getting registered at all. I thought that it was no longer possible to register packages with unversioned dependencies. See ticket #1837. What's going on? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 21:24:28 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 21:20:21 2008 Subject: [GHC] #2705: ghc does not report haskell98's version number. In-Reply-To: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> References: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> Message-ID: <061.1bbb16c6c4e819f7e32f4421b86ec866@localhost> #2705: ghc does not report haskell98's version number. ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by thoughtpolice): Duncan, Me and David are thinking about some ways in which we can solve the problem, since right now that particular part of the configuration code is a little weak. It works fine for right now, but of course we'll likely go with something more robust in the future. Also, I can confirm a package with unversioned dependencies can be registered (for any dependency) with 'ghc-pkg register' without --force or any error output on the 6.10 RC1, so I'm not sure what's going on either. (P.S. this also occurs with the ghc-prim package on 6.10.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 22:46:36 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 22:42:28 2008 Subject: [GHC] #1837: ghc-pkg should not accept unversioned depends In-Reply-To: <045.5a240ed44745ae5d43f18d5941f21a30@localhost> References: <045.5a240ed44745ae5d43f18d5941f21a30@localhost> Message-ID: <054.9cfe359b3f36d6eccc402ac0f95c7641@localhost> #1837: ghc-pkg should not accept unversioned depends ------------------------------+--------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.8.2 Component: Build System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by duncan): * status: closed => reopened * type: merge => bug * resolution: fixed => Comment: It seems there is a regression here. See #2705. Apparently unversionend dependencies are silently allowed. It might be that's because "foo" gets parsed as a package id as `PackageId "foo" (Version [] [])`, ie an empty version. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 22:48:54 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 22:44:46 2008 Subject: [GHC] #2705: ghc does not report haskell98's version number. In-Reply-To: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> References: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> Message-ID: <061.dec7a2f2a8b4fa6426fedb1663c3eeec@localhost> #2705: ghc does not report haskell98's version number. ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:3 thoughtpolice]: > Also, I can confirm a package with unversioned dependencies can be registered (for any dependency) with 'ghc-pkg register' without --force or any error output on the 6.10 RC1, so I'm not sure what's going on either. Ok, I've reopened ticket #1837. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 16 23:02:17 2008 From: trac at galois.com (GHC) Date: Thu Oct 16 22:58:11 2008 Subject: [GHC] #2706: Associated data type doesn't infer context Message-ID: <042.a629ccca5b942ee9604b09e193491b02@localhost> #2706: Associated data type doesn't infer context ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ The following code fails to compile: {{{ class Eq a => Bar a where bar :: a -> Int class Bar (Baz a) => Foo a where data Baz a :: * foo :: Baz a -> Baz a data Bang a = Bang (Baz a) deriving Eq }}} The error message is {{{ test.hs:8:36: No instance for (Eq (Baz a)) arising from the 'deriving' clause of a data type declaration at test.hs:8:36-37 Possible fix: add an instance declaration for (Eq (Baz a)) When deriving the instance for (Eq (Bang a)) }}} If I add a context of {{{Foo a}}} to {{{Bang}}}, it compiles, but since {{{Baz}}} is only defined on instances of {{{Foo}}}, shouldn't GHC be able to figure out that {{{Baz a}}} always has an {{{Eq}}} instance? In any case, the error message is misleading, since there already ''is'' a context for {{{Baz a}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 17 03:46:17 2008 From: trac at galois.com (GHC) Date: Fri Oct 17 03:42:08 2008 Subject: [GHC] #2706: Associated data type doesn't infer context In-Reply-To: <042.a629ccca5b942ee9604b09e193491b02@localhost> References: <042.a629ccca5b942ee9604b09e193491b02@localhost> Message-ID: <051.52dd1af341889d3a3c97388af89c4ee4@localhost> #2706: Associated data type doesn't infer context ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: I'm afraid the error message is fine. `(Baz a)` does not have an `Eq` instance. It's true that if you have a `(Foo a)` dictionary then you have a `Bar (Baz a)` dictionary (since that's a superclass), and hence you have an `Eq (Baz a)` dictionary (since `Eq` is a superclass of `Bar`). But you don't have a `(Foo a)` dictionary in the derived instance. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 17 06:37:11 2008 From: trac at galois.com (GHC) Date: Fri Oct 17 06:33:03 2008 Subject: [GHC] #2707: GHCi reports "exitWith ExitSuccess" as an exception Message-ID: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> #2707: GHCi reports "exitWith ExitSuccess" as an exception ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Consider the following behaviour. {{{ mfn@pc149:~$ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m System.Exit Prelude System.Exit> exitWith ExitSuccess *** Exception: exit: ExitSuccess Prelude System.Exit> }}} Is this desired --- i.e. is a successfull exit worth shouting about? Matthew Naylor (`mfn@cs.york.ac.uk`) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 17 10:39:39 2008 From: trac at galois.com (GHC) Date: Fri Oct 17 10:35:30 2008 Subject: [GHC] #2705: ghc does not report haskell98's version number. In-Reply-To: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> References: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> Message-ID: <061.5eed0151db804d4306150246f5fa7493@localhost> #2705: ghc does not report haskell98's version number. ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by droundy): * cc: daveroundy@darcs.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 17 10:39:58 2008 From: trac at galois.com (GHC) Date: Fri Oct 17 10:35:50 2008 Subject: [GHC] #2705: ghc does not report haskell98's version number. In-Reply-To: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> References: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> Message-ID: <061.9cbc907aedf2c217a993a73904a2a94b@localhost> #2705: ghc does not report haskell98's version number. ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by droundy): * cc: daveroundy@darcs.net (removed) * cc: droundy@darcs.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 17 14:45:34 2008 From: trac at galois.com (GHC) Date: Fri Oct 17 14:41:57 2008 Subject: [GHC] #2704: "403 Forbidden" on recent 6.10.0 snapshot tarballs In-Reply-To: <045.f66631efa340d18e5e794d3248ba9c50@localhost> References: <045.f66631efa340d18e5e794d3248ba9c50@localhost> Message-ID: <054.f113dcdf10beebfa9be20781f00b7998@localhost> #2704: "403 Forbidden" on recent 6.10.0 snapshot tarballs ------------------------------+--------------------------------------------- Reporter: ingmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. I've fixed the permission on the existing files, and Simon's fixed the umask so that future uploads will have the right perms. -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Fri Oct 17 18:20:14 2008 From: conal at conal.net (Conal Elliott) Date: Fri Oct 17 18:16:06 2008 Subject: OpenGL+GLUTwith ghc-6.10 ? Message-ID: Has anyone gotten OpenGL+GLUT to work with ghc-6.10? It crashes for me on createWindow (from Graphics.UI.GLUT.Window). I'm using the ghc-6.10.0.20081007 from a win32 installer, along with OpenGL-2.2.1.1 and GLUT-2.1.1.2 from Hackage. Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20081017/bbda71b6/attachment-0001.htm From trac at galois.com Sat Oct 18 18:51:12 2008 From: trac at galois.com (GHC) Date: Sat Oct 18 18:47:07 2008 Subject: [GHC] #2708: Error message should suggest UnboxedTuples language extension Message-ID: <042.212746937576e763576cc00131665374@localhost> #2708: Error message should suggest UnboxedTuples language extension ---------------------------------+------------------------------------------ Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ If I compile this code: {{{ module Foo where import GHC.Integer foo x y = case x `quotRemInteger` y of (# y, z #) -> 42 }}} I get: {{{ foo.hs:7:5: Parse error in pattern }}} It would be better if the error message suggested using {{{-XUnboxedTuples}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 01:07:16 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 01:04:13 2008 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.acdbb2df5acfdf561cb5d5f6c1bfa964@localhost> #1673: Template Haskell support for type families ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by ajd): * cc: alexander.dunlap@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 06:10:35 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 06:06:20 2008 Subject: [GHC] #2709: System.Directory.doesDirectoryExist "\\" is False on Windows Message-ID: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> #2709: System.Directory.doesDirectoryExist "\\" is False on Windows ---------------------------------+------------------------------------------ Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Windows ---------------------------------+------------------------------------------ {{{ import System.Directory main = do print =<< doesDirectoryExist "\\" print =<< doesDirectoryExist "\\." }}} The above prints `False` followed by `True`, and both should definitely be `True`. It seems like it might even be a bug in MinGW or the MSVCRT. The following does work, giving both as `True`: {{{ import Data.Bits import System.Win32.Types import System.Win32.File doesDirectoryExist = flip withTString $ \s -> do a <- c_GetFileAttributes s return (a /= 0xffffffff && a.&.fILE_ATTRIBUTE_DIRECTORY /= 0) main = do print =<< doesDirectoryExist "\\" print =<< doesDirectoryExist "\\." }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 09:08:27 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 09:04:13 2008 Subject: [GHC] #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib In-Reply-To: <043.cf6c9356908d84d15cb72785d970ada9@localhost> References: <043.cf6c9356908d84d15cb72785d970ada9@localhost> Message-ID: <052.187ef668658721794ae69744429ab02b@localhost> #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib ----------------------+----------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 09:09:00 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 09:04:44 2008 Subject: [GHC] #2684: Stack overflow in stream-fusion library with GHC 6.10 RC In-Reply-To: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> References: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> Message-ID: <052.e45c57a13486e7a0553c083861047c57@localhost> #2684: Stack overflow in stream-fusion library with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 14:27:41 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 14:23:24 2008 Subject: [GHC] #2711: haddock contents/index includes hidden modules (broken links) Message-ID: <044.fbfe2f60930b12a4a437841b14560394@localhost> #2711: haddock contents/index includes hidden modules (broken links) ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Lots of supposedly hidden modules are listed in the haddock contents and index page. These link to non-existent HTML pages. The cause is http://trac.haskell.org/haddock/ticket/62 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 14:28:38 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 14:24:21 2008 Subject: [GHC] #2711: haddock contents/index includes hidden modules (broken links) In-Reply-To: <044.fbfe2f60930b12a4a437841b14560394@localhost> References: <044.fbfe2f60930b12a4a437841b14560394@localhost> Message-ID: <053.798b1e39ea2fee38f7f792b6225b9676@localhost> #2711: haddock contents/index includes hidden modules (broken links) ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by igloo): Examples: GHC.Read, Data.Array.Parallel.Lifted.Closure. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 14:38:17 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 14:34:02 2008 Subject: [GHC] #2657: DPH Haddock document isn't linked from Libraries document In-Reply-To: <047.3ea7891160068f161ef63cd3e40d298b@localhost> References: <047.3ea7891160068f161ef63cd3e40d298b@localhost> Message-ID: <056.2252aa5f17048868cfa4d11940c0fe53@localhost> #2657: DPH Haddock document isn't linked from Libraries document ------------------------------+--------------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We've got the same problem with, for example, a load of GHC.* modules, so I've pushed the patch to add DPH to the doc contents/index. I've made new tickets for the problem: #2711, http://trac.haskell.org/haddock/ticket/62 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 15:29:54 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 15:25:50 2008 Subject: [GHC] #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown-linux-libedit2 In-Reply-To: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> References: <045.45308f6d748b03181ff7f34aed1e95c8@localhost> Message-ID: <054.adedc1875be3449bee54687603830d55@localhost> #2691: runghc sets terminal ctrl-s to XOFF in ghc-6.10.0.20081007-i386-unknown- linux-libedit2 ----------------------+----------------------------------------------------- Reporter: dancor | Owner: judah Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied and merged to 6.10, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 16:44:11 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 16:40:00 2008 Subject: [GHC] #2698: Windows binary distribution pops up README.TXT for the source distribution In-Reply-To: <045.bc598ef2cae0aae707dbc598e8bfe53c@localhost> References: <045.bc598ef2cae0aae707dbc598e8bfe53c@localhost> Message-ID: <054.73b50374b8200464d7891e2afd081ed9@localhost> #2698: Windows binary distribution pops up README.TXT for the source distribution ----------------------+----------------------------------------------------- Reporter: ganesh | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo Comment: Agreed: It doesn't seem to say anything useful, so I'll remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 19 17:00:28 2008 From: trac at galois.com (GHC) Date: Sun Oct 19 16:56:17 2008 Subject: [GHC] #2697: bad testsuite results with ghc-6.10.0.20081007 In-Reply-To: <045.c368cc178489a6d371c14b6319d3b743@localhost> References: <045.c368cc178489a6d371c14b6319d3b743@localhost> Message-ID: <054.69ce5485e0961769d26d38d94c14b3cd@localhost> #2697: bad testsuite results with ghc-6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by igloo): In the Mac log, most of the failures seem to be due to not finding `gmp.h`; do you know what the problem is with that? I'm just merging a patch to fix the hpc failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 04:29:30 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 04:25:13 2008 Subject: [GHC] #2702: having build issues with ghc 6.6.1 In-Reply-To: <047.9af5f2bef03f66c96c590fff08693d38@localhost> References: <047.9af5f2bef03f66c96c590fff08693d38@localhost> Message-ID: <056.16a66def4abea82e059a1ee9c4cb0b41@localhost> #2702: having build issues with ghc 6.6.1 ----------------------+----------------------------------------------------- Reporter: wnyrodeo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: critical | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Reporter was able to get GHC installed after help from others on cvs- ghc@haskell.org. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 04:32:50 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 04:28:36 2008 Subject: [GHC] #2697: bad testsuite results with ghc-6.10.0.20081007 In-Reply-To: <045.c368cc178489a6d371c14b6319d3b743@localhost> References: <045.c368cc178489a6d371c14b6319d3b743@localhost> Message-ID: <054.3eb237539854044769c042261fdb3e63@localhost> #2697: bad testsuite results with ghc-6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by maeder): Replying to [comment:2 igloo]: > In the Mac log, most of the failures seem to be due to not finding `gmp.h`; do you know what the problem is with that? It seems my CPATH and LD_LIBRARY_PATH was not set to `/opt/local/{include,lib}` when running the test suite (as was the case when building) Usually I copy gmp.h and libgmp.a manually to the installation place so that my created binaries do not rely on a dynamic libgmp. My fault. Cheers Christian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 04:34:07 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 04:29:49 2008 Subject: [GHC] #2707: GHCi reports "exitWith ExitSuccess" as an exception In-Reply-To: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> References: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> Message-ID: <053.73e361079339172274c9270efaaf22c9@localhost> #2707: GHCi reports "exitWith ExitSuccess" as an exception ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: I can see arguments both ways. `ExitSuccess` is an exception like any other, and GHCi reports all exceptions - this might be helpful for the user if they weren't aware that `exitWith` raised an exception. On the other hand, `ExitSuccess` doesn't cause any output in a standalone program. Anyone else have any thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 04:45:45 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 04:41:28 2008 Subject: [GHC] #2705: ghc discards version of wired-in packages In-Reply-To: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> References: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> Message-ID: <061.e2e7cff91007797337aaea3407bedd2a@localhost> #2705: ghc discards version of wired-in packages ------------------------------+--------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * summary: ghc does not report haskell98's version number. => ghc discards version of wired-in packages * milestone: => _|_ Comment: This will happen for any of the "wired-in" packages. The current list of wired-in packages is {{{ ghc-prim integer base (the new one, not base-3.0.3.0) rts haskell98 syb template-haskell dph-seq dph-par }}} For these, we internally use unversioned package Ids, because GHC needs to refer to entities in these packages without knowing their version numbers. So I agree that technically the error message is wrong, but it's not easy to fix because we've thrown away the version information about these packages. I agree with Duncan that parsing these error message to figure out which packages to enable is a bad idea. For instance, it told you about "base-3.0.3.0", when you probably wanted "base-4.0.0.0". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 04:46:16 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 04:41:58 2008 Subject: [GHC] #2707: GHCi reports "exitWith ExitSuccess" as an exception In-Reply-To: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> References: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> Message-ID: <053.4ff9ed31cffb705084b7aa46d454b0ea@localhost> #2707: GHCi reports "exitWith ExitSuccess" as an exception ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by NeilMitchell): I'd suggest that no output is appropriate. The fact that exit success is implemented as an exception is an internal detail, as exceptions are typically for exceptional conditions. It also mirrors the standalone behaviour, which is a good thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 04:50:46 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 04:46:27 2008 Subject: [GHC] #2703: Buffer overflow, occasional segfaults when using handles created by Network. In-Reply-To: <043.0b636667312adf746bdfc543d5231d22@localhost> References: <043.0b636667312adf746bdfc543d5231d22@localhost> Message-ID: <052.433aea604997fbee069575b8af207b2d@localhost> #2703: Buffer overflow, occasional segfaults when using handles created by Network. -------------------------------+-------------------------------------------- Reporter: sclv | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.10.1 Comment: I'll investigate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 05:55:46 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 05:51:28 2008 Subject: [GHC] #2707: GHCi reports "exitWith ExitSuccess" as an exception In-Reply-To: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> References: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> Message-ID: <053.8984cd5a91e1f19dd6fdbcce880c6b68@localhost> #2707: GHCi reports "exitWith ExitSuccess" as an exception ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Replying to [comment:2 NeilMitchell]: > I'd suggest that no output is appropriate. The fact that exit success is implemented as an exception is an internal detail, as exceptions are typically for exceptional conditions. It also mirrors the standalone behaviour, which is a good thing. It's not just an implementation detail - the fact that `ExitSuccess` is an exception means that you can use things like `Control.Exception.finally` to run code on program exit, regardless of whether the program exits successfully or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 05:56:30 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 05:52:16 2008 Subject: [GHC] #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 In-Reply-To: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> References: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> Message-ID: <058.3fc80866051c4878283ec9aef3eea57e@localhost> #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: panic | Difficulty: Unknown Testcase: | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by chak): * owner: => chak * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 06:21:16 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 06:16:58 2008 Subject: [GHC] #2628: hIsTerminalDevice returns True for /dev/null (aka NUL) on Windows In-Reply-To: <044.c1bd1c3ac0471340a6fae29b24f965a3@localhost> References: <044.c1bd1c3ac0471340a6fae29b24f965a3@localhost> Message-ID: <053.b11278e152ec6c3dc43db348956c75fc@localhost> #2628: hIsTerminalDevice returns True for /dev/null (aka NUL) on Windows ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: 2228 | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * summary: isatty behaves unexpectedly on mingw => hIsTerminalDevice returns True for /dev/null (aka NUL) on Windows * milestone: 6.10.2 => _|_ Comment: `isatty` does indeed return non-zero for NUL on Windows. In fact, `GetFileType` also returns `FILE_TYPE_CHAR` for NUL, so it seems hard to tell them apart. I'm not planning to do anything about this except for marking the bug as an expected failure, it's a fairly rare corner-case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 06:39:39 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 06:35:21 2008 Subject: [GHC] #2705: ghc discards version of wired-in packages In-Reply-To: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> References: <052.8bbfb1775dd9fe9c089b9b4c8f84650e@localhost> Message-ID: <061.3c8ee12c5b8f0aedf649e4fd2a1d7dfd@localhost> #2705: ghc discards version of wired-in packages ------------------------------+--------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by claus): Does this help? {{{ $ cat x.hs module Main where import System import Prelude main = do p <- getProgName putStrLn $ "program name is " ++ p $ ghc -e ":set -v" -e ":show packages" x.hs wired-in package base mapped to base-3.0.2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. active package flags: none packages currently loaded: base rts }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 06:43:55 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 06:39:38 2008 Subject: [GHC] #2707: GHCi reports "exitWith ExitSuccess" as an exception In-Reply-To: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> References: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> Message-ID: <053.0c1dfe48b56f86d520108e9a60b96ab7@localhost> #2707: GHCi reports "exitWith ExitSuccess" as an exception ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by claus): Replying to [comment:3 simonmar]: > Replying to [comment:2 NeilMitchell]: > > I'd suggest that no output is appropriate. > It's not just an implementation detail - the fact that `ExitSuccess` is an exception means that you can use things like `Control.Exception.finally` to run code on program exit, regardless of whether the program exits successfully or not. Would it work to wrap the whole thing (including any `finally`s) in a handler that discards surviving `ExitSuccess`es by default, with a flag to disable the default wrapping? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 06:46:59 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 06:43:20 2008 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.10260b8eff630ead0ee5e737809d01b5@localhost> #1346: bootstrap from HC files ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by CBa): * cc: ich@christoph-bauer.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 10:01:16 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 09:56:58 2008 Subject: [GHC] #2707: GHCi reports "exitWith ExitSuccess" as an exception In-Reply-To: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> References: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> Message-ID: <053.8fe3e71564c6d72b4ad381736644dbc6@localhost> #2707: GHCi reports "exitWith ExitSuccess" as an exception ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by simonmar): Replying to [comment:4 claus]: > Would it work to wrap the whole thing (including any `finally`s) in a handler that discards surviving `ExitSuccess`es by default, with a flag to disable the default wrapping? Sure - the question is whether we ''should'' do that. (and having a flag is a bit of a cop-out, though admittedly a cop-out we often employ :-)). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 10:05:20 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 10:01:02 2008 Subject: [GHC] #2703: Buffer overflow, occasional segfaults when using handles created by Network. In-Reply-To: <043.0b636667312adf746bdfc543d5231d22@localhost> References: <043.0b636667312adf746bdfc543d5231d22@localhost> Message-ID: <052.3802fc4abad784be40568f052ad036e3@localhost> #2703: Buffer overflow, occasional segfaults when using handles created by Network. -------------------------------+-------------------------------------------- Reporter: sclv | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.1 Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: I've found and fixed the cause of the hang, but the segfault eludes me. I've seen it once (it generated a 6.9GB core file that locked up our NFS server for quite a while :-) but I've been unable to reproduce it since. I suspect there's an inaccurate stack check somewhere, but finding those is particuarly hard. The best we can hope for is that the crash resurfaces in another way, or (optimistically) that it's already been fixed. {{{ Mon Oct 20 05:11:03 PDT 2008 Simon Marlow * FIX (partially) #2703: bug in stack overflow handling when inside block As a result of a previous ticket (#767) we disabled the generation of StackOverflow exceptions when inside a Control.Exception.block, on the grounds that StackOverflow is like an asynchronous exception. Instead we just increase the stack size. However, the stack size calculation was wrong, and ended up not increasing the size of the stack, with the result that the runtime just kept re-allocating the stack and filling up memory. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 11:40:32 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 11:36:16 2008 Subject: [GHC] #2712: Parallel GC scheduling problems Message-ID: <047.e61225a9faf204b963254a4027c9403b@localhost> #2712: Parallel GC scheduling problems -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: simonmar Type: run-time performance bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Moderate (1 day) | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------+---------------------------------- The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently. Really we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks. If this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 14:01:43 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 13:57:26 2008 Subject: [GHC] #2707: GHCi reports "exitWith ExitSuccess" as an exception In-Reply-To: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> References: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> Message-ID: <053.0ca75bb16f4be728b2297e74bdac4463@localhost> #2707: GHCi reports "exitWith ExitSuccess" as an exception ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by duncan): I think the current behaviour is perfectly sensible. It gives you the result of your action, which is an exception saying it exited sucessfully. It's not as if it's giving a page of scary error messages. If it's too scary then change the printing within ghci of "non scary" exceptions like exit and `^C`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 14:50:38 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 14:46:19 2008 Subject: [GHC] #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 Message-ID: <049.253b91b6ac2808a333ea293682ed290c@localhost> #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 ---------------------------------+------------------------------------------ Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ {{{ {-# LANGUAGE TemplateHaskell #-} module Fixity where class MyClass a where (.*.) :: a -> a -> a main = putStrLn "hi" -- $( [d| x = undefined |] ) infixr 3 .*. }}} Compiling the above with: {{{c:\ghc\ghc-6.10.0.20081007\bin\ghc.exe --make -ddump-hi ~/Fixity.hs}}} gives: {{{ ==================== FINAL INTERFACE ==================== interface main:Fixity 610020081007 interface hash: 791ca25a8ddea4dee47d108320bf5b50 ABI hash: c2ca52d8c1ffc89265effb15d766f4aa export-list hash: 9613c0af035884a108b9bebc1c0b08b6 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e where export main:Fixity MyClass|{.*. MyClass} main module dependencies: package dependencies: ghc-prim integer base orphans: base:Control.Exception.Base base:Data.Tuple base:GHC.Base base:GHC.Float base:GHC.Num family instance modules: import base:Prelude eac9ca3c0ae6d00a0fc0f1832a247e5e import base:System.IO 9fa582151667de94fbfb9074e3c0f1b4 fixities infixr 3 .*. 1bcd9343d420eae1078ef2fa9021dbf8 class MyClass a RecFlag NonRecursive .*. :: a -> a -> a 96fb86d3649acbcf89c1f2802a511b0e main :: GHC.IOBase.IO () vectorised variables: vectorised tycons: vectorised reused tycons: }}} Which is fine. Uncommenting the TH line and recompiling though gives: {{{ ==================== FINAL INTERFACE ==================== interface main:Fixity 610020081007 interface hash: 0a7949a029127113f8c49434e22bcb71 ABI hash: 3e2e66371e835a766a2fdedd54cb2c35 export-list hash: 73f4a7845d4b5048d9321b0e99b46428 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e where export main:Fixity MyClass|{.*. MyClass} main x module dependencies: package dependencies: ghc-prim integer base template-haskell orphans: base:Control.Exception.Base base:Data.Tuple base:GHC.Base base:GHC.Float base:GHC.Num family instance modules: import base:GHC.Err 357889242e9fa603050a70e6dac2a5e4 import base:Prelude eac9ca3c0ae6d00a0fc0f1832a247e5e import base:System.IO 9fa582151667de94fbfb9074e3c0f1b4 852943708ad257bdcf76e94914bb84b2 class MyClass a RecFlag NonRecursive .*. :: a -> a -> a 96fb86d3649acbcf89c1f2802a511b0e main :: GHC.IOBase.IO () 41850025600a6740465944638d138bc4 x :: forall a. a vectorised variables: vectorised tycons: vectorised reused tycons: }}} ...ie the "fixities" entry is lost. This worked fine in 6.8.2. http://hackage.haskell.org/trac/ghc/ticket/2632 may be related - but that was marked as closed/merged on 4th Oct, and I'm using a GHC 20081007. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 16:46:10 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 16:42:38 2008 Subject: [GHC] #2714: No match in record selector Var.tcTyVarDetails Message-ID: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> #2714: No match in record selector Var.tcTyVarDetails -----------------------------------------------------+---------------------- Reporter: morrow | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: Var, tcTyVarDetails, record selector | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------------------+---------------------- Summary: {{{ ghci> :t fmap :: ((a -> b) -> b) -> (forall c. c -> a) *** Exception: No match in record selector Var.tcTyVarDetails }}} I stumbled across this while in ghci with flags: {{{ :set -fglasgow-exts -O2 -fno-print-bind-result :set -XQuasiQuotes -XTemplateHaskell }}} Beginning with where I came across it and proceeding in reverse chrono order wrt ghc versions: {{{ [m@ganon feio]$ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.10.0.20080927 ghci> :t fmap :: ((a -> b) -> b) -> (forall c. c -> a) *** Exception: No match in record selector Var.tcTyVarDetails }}} {{{ [m@ganon feio]$ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.9.20080504 ghci> :t fmap :: ((a -> b) -> b) -> (forall c. c -> a) *** Exception: No match in record selector Var.tcTyVarDetails }}} {{{ [m@ganon feio]$ /usr/bin/ghc-6.8.2 -V The Glorious Glasgow Haskell Compilation System, version 6.8.2 ghci> :t fmap :: ((a -> b) -> b) -> (forall c. c -> a) :1:0: Couldn't match expected type `c' against inferred type `f (f b -> b)' `c' is a rigid type variable bound by the polymorphic type `forall c. c -> a' at :1:0 Probable cause: `fmap' is applied to too few arguments :1:0: Couldn't match expected type `a' against inferred type `f b' `a' is a rigid type variable bound by the polymorphic type `forall a b. ((a -> b) -> b) -> forall c. c -> a' at :1:0 Probable cause: `fmap' is applied to too few arguments }}} {{{ [m@ganon feio]$ /usr/bin/ghc-6.8.1 -V The Glorious Glasgow Haskell Compilation System, version 6.8.1 ghci> :t fmap :: ((a -> b) -> b) -> (forall c. c -> a) :1:0: Couldn't match expected type `c' against inferred type `f (f b -> b)' `c' is a rigid type variable bound by the polymorphic type `forall c. c -> a' at :1:0 Probable cause: `fmap' is applied to too few arguments }}} Aside from filing a bug rpt, I'm curious in general about what change to whathaveyou, some way or another, had this as a side-effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 19:44:03 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 19:39:43 2008 Subject: [GHC] #2715: GHC panic Message-ID: <047.797aaec011bad118fea0580e1c0ce283@localhost> #2715: GHC panic -------------------------+-------------------------------------------------- Reporter: rodprice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- The code in "bug.hs" causes a GHC panic; the nearly identical code in "unbug.hs" does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 19:49:00 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 19:44:40 2008 Subject: [GHC] #2715: GHC panic In-Reply-To: <047.797aaec011bad118fea0580e1c0ce283@localhost> References: <047.797aaec011bad118fea0580e1c0ce283@localhost> Message-ID: <056.c17fb833418c6f215af79bd5bb1469ac@localhost> #2715: GHC panic -------------------------+-------------------------------------------------- Reporter: rodprice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by rodprice): Here's the error message: stm$ ghci bug.hs GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for i386-unknown-linux): applyTypeToArgs main:Main.:DIIDomain{v rmQ} [gid] @ main:Main.Interval{tc rfz} @ main:Main.Interval{tc rfz} $dIDomain{v an6} [lid] $dIDomain{v an7} [lid] @ (main:Main.Value{tc rfv} main:Main.Interval{tc rfz}) (main:Main.Value{tc rfv} main:Main.Interval{tc rfz} ~ main:Main.Value{tc rfv} main:Main.Interval{tc rfz}, main:Main.IDomain{tc rfr} main:Main.Interval{tc rfz}, main:Main.IDomain{tc rfr} main:Main.Interval{tc rfz}) => (main:Main.Domain{tc rfx} main:Main.Interval{tc rfz} (main:Main.Value{tc rfv} main:Main.Interval{tc rfz}) -> main:Main.Domain{tc rfx} main:Main.Interval{tc rfz} (main:Main.Value{tc rfv} main:Main.Interval{tc rfz}) -> ghc-prim:GHC.Bool.Bool{(w) tc 3c}) -> main:Main.Interval{tc rfz} main:Main.:TIIDomain{tc rmP} main:Main.Interval{tc rfz} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 20 23:57:25 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 23:53:13 2008 Subject: [GHC] #2708: Error message should suggest UnboxedTuples language extension In-Reply-To: <042.212746937576e763576cc00131665374@localhost> References: <042.212746937576e763576cc00131665374@localhost> Message-ID: <051.2972ba2d0580a45ff890b0fbe1ce354e@localhost> #2708: Error message should suggest UnboxedTuples language extension -------------------------------+-------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler (Parser) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------+-------------------------------------------- Changes (by simonpj): * priority: normal => low * difficulty: => Unknown * milestone: => _|_ Comment: It would be better, yes. And usually I'm very keen to improve error messages. The reason we don't is that `-XUnboxedTuples` tells the ''lexical analyser'' to recognise the lexemes `(#` and `#)`. The idea is not to interfere with Haskell 98 when the extension is switched off. For example `(# 3)` is a section in H98. So just seeing `(#` isn't enough to say "I suggest you use `-XUnboxedTuples`". So that's why it's tricky. I can't see an easy way to give you want you ask. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 00:02:05 2008 From: trac at galois.com (GHC) Date: Mon Oct 20 23:57:45 2008 Subject: [GHC] #2715: GHC panic In-Reply-To: <047.797aaec011bad118fea0580e1c0ce283@localhost> References: <047.797aaec011bad118fea0580e1c0ce283@localhost> Message-ID: <056.ab5889d856fcdf230d736186c9568beb@localhost> #2715: GHC panic ----------------------+----------------------------------------------------- Reporter: rodprice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Ah, you are using an equality predicate in the superclass context {{{ class (Value d1 ~ Value d2) => IIDomain d1 d2 where }}} This specifically does not work in 6.10; it's the major unfinished piece in the type-family story. Really GHC 6.10 should simply reject such programs. As it stands, it has a half-baked go at it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 01:05:55 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 01:01:35 2008 Subject: [GHC] #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) Message-ID: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) -------------------------------+-------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: critical Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- I've been trying out ghc 6.10 snapshots and I just discovered that ghci isn't usable for me. I'm running Gentoo on amd64 and I've both compiled 6.10 myself (using a variant of the ebuild from the Gentoo haskell overlay) and downloaded binary snapshots from haskell.org/ghc/dist/stable/dist (playing games with libedit.so to get them to work). In both cases, ghci starts sucking up enormous amounts of memory on startup (quickly getting to 1.5G before my machine starts swapping - without loading any packages other than ghc-prim, integer and base). I've specifically observed this problem with 6.10.0.20081007 (i.e. RC1, if I'm reading things correctly), 6.10.0.20081019 and 6.10.0.20081020. I don't know what's going on, but I didn't have this problem with ghc 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 01:07:54 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 01:03:37 2008 Subject: [GHC] #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint In-Reply-To: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> References: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> Message-ID: <060.ac339dbdba5e6e6de02533c3af69b1e6@localhost> #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint ------------------------------+--------------------------------------------- Reporter: PVerswyvelen | Owner: chak Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2688 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by chak): * testcase: => T2688 * status: new => closed * resolution: => fixed Comment: Igloo: Thanks for doing the trace. That put me on the right trail straight away. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 02:35:52 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 02:31:32 2008 Subject: [GHC] #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) In-Reply-To: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> References: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> Message-ID: <052.c967f163cb4a853cb8fc4145abebd4ee@localhost> #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) ----------------------+----------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Can you give us a test case? Without that it's hard to help. Or are you saying that simply typing "ghci" eats 1.5G? That ''would'' be strange. Many thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 03:01:08 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 02:56:50 2008 Subject: [GHC] #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) In-Reply-To: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> References: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> Message-ID: <052.4e0247b528fe0d170777a319ef513949@localhost> #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) ----------------------+----------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by duncan): We have seen this kind behaviour before with older ghc releases. Superficially it looks similar to this report: #778 or http://bugs.gentoo.org/show_bug.cgi?id=135651 That time it was caused by a newer gcc mis-compiling some part of the RTS. Ravi: could you get an strace log of starting ghci and attach it to this ticket. Could you also attach the output of `emerge --info`. That would help us, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 04:42:35 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 04:38:17 2008 Subject: [GHC] #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) In-Reply-To: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> References: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> Message-ID: <052.310364010de79cfe941e9ee8a3197309@localhost> #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) ----------------------+----------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * priority: normal => high * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 04:52:52 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 04:48:45 2008 Subject: [GHC] #2717: Add nubWith, nubOrd Message-ID: <050.81576ece7ea2f3fe706671e03fa58430@localhost> #2717: Add nubWith, nubOrd ---------------------------------+------------------------------------------ Reporter: Bart Massey | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ This is a followup to my proposal #2629, which had a much more ambitious scheme. After much discussion, it was decided to put this smaller proposal on the table. I've implemented a new function Data.List.nubWith that takes a "stop list" and "filtering function" as an argument, and filters its target list against the stop list. I've then implemented Data.Set.nubOrd in terms of nubWith. nubBy is left alone, since there's nothing obvious to be done about it. All of the nubs are still fully lazy. Basic QuickCheck tests have been written, and pass. Performance benchmarking shows my nubOrd implementation to be quite comparable to that of nub in cases where the latter performs well, and dramatically faster when nub performs poorly. In particular, nubOrd can work on long lists with long nubs, unlike the basic nub, which is hopeless. Patch against current Darcs head attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 04:55:32 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 04:51:23 2008 Subject: [GHC] #2717: Add nubWith, nubOrd In-Reply-To: <050.81576ece7ea2f3fe706671e03fa58430@localhost> References: <050.81576ece7ea2f3fe706671e03fa58430@localhost> Message-ID: <059.3e912d9df410863652b674b010f18c77@localhost> #2717: Add nubWith, nubOrd ---------------------------------+------------------------------------------ Reporter: Bart Massey | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by Bart Massey): Discussion period two weeks, until 2008/11/3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 04:56:56 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 04:52:48 2008 Subject: [GHC] #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <050.f409c69b6469259efa640144979533d8@localhost> References: <050.f409c69b6469259efa640144979533d8@localhost> Message-ID: <059.8a9a13bb69396083c16ba4967894d555@localhost> #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith ------------------------------+--------------------------------------------- Reporter: Bart Massey | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by Bart Massey): * status: new => closed * resolution: => invalid Comment: Superseded by proposal #2717 . -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 05:57:35 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 05:53:19 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.0abf88695e102534e3c85d0983416c4f@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by Svarog): Replying to [comment:15 simonmar]: Yes, you are right. I've rewritten the patches from scratch and hopefully the new patches address all the problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 06:29:47 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 06:25:53 2008 Subject: [GHC] #2714: No match in record selector Var.tcTyVarDetails In-Reply-To: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> References: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> Message-ID: <054.7c269a37812425ef95882a02bb6790d1@localhost> #2714: No match in record selector Var.tcTyVarDetails -----------------------------------------------------+---------------------- Reporter: morrow | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: Var, tcTyVarDetails, record selector | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------------------+---------------------- Comment (by morrow): Judging from the comment, this may have something to do with it? From TcUnify: {{{ unBox :: BoxyType -> TcM TcType -- ... unBox (TyVarTy tv) | isTcTyVar tv -- It's a boxy type variable , MetaTv BoxTv ref <- tcTyVarDetails tv -- NB: non-TcTyVars are possible = do { cts <- readMutVar ref -- under nested quantifiers -- ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 06:35:16 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 06:31:35 2008 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> Message-ID: <053.710299bba0ecf1a94531080fa799a2a7@localhost> #1475: Adding imports and exports with Template Haskell ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by morrow): * cc: mjm2002@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 06:36:40 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 06:32:50 2008 Subject: [GHC] #2041: Allow splicing in concrete syntax In-Reply-To: <044.42309534ba1bde34757106bdf2d7d6ae@localhost> References: <044.42309534ba1bde34757106bdf2d7d6ae@localhost> Message-ID: <053.7acd9275818e7e8f6d89404ce863e84f@localhost> #2041: Allow splicing in concrete syntax ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by morrow): * cc: mjm2002@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 06:37:52 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 06:34:27 2008 Subject: [GHC] #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets In-Reply-To: <045.d93d26e0bae3aef3676683e1847e945d@localhost> References: <045.d93d26e0bae3aef3676683e1847e945d@localhost> Message-ID: <054.73c1424b5f3ad0f186bf796583218959@localhost> #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets -------------------------------------+-------------------------------------- Reporter: sorear | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by morrow): * cc: mjm2002@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 06:38:29 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 06:34:54 2008 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.69b62bd89e0efa8c1c8797df368dc6b0@localhost> #1895: Allow aliases in GHCi module imports ------------------------------+--------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by morrow): * cc: mjm2002@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 06:40:51 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 06:37:05 2008 Subject: [GHC] #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma In-Reply-To: <047.0b0f638b3610964bc1921eacae64b292@localhost> References: <047.0b0f638b3610964bc1921eacae64b292@localhost> Message-ID: <056.93dc5e94a14cdeecdcf1f91aeced080f@localhost> #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma ------------------------------+--------------------------------------------- Reporter: mnislaih | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by morrow): * cc: mjm2002@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 06:58:34 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 06:54:40 2008 Subject: [GHC] #2714: No match in record selector Var.tcTyVarDetails In-Reply-To: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> References: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> Message-ID: <054.632184cbad281cc16a28e0689e97e8c7@localhost> #2714: No match in record selector Var.tcTyVarDetails -----------------------------------------------------+---------------------- Reporter: morrow | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: Var, tcTyVarDetails, record selector | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------------------+---------------------- Comment (by morrow): I just came across ticket #1123, which seems possibly related. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 07:30:58 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 07:26:38 2008 Subject: [GHC] #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) In-Reply-To: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> References: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> Message-ID: <052.53e62121930843dc6250ef9a4e4b60b0@localhost> #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) ----------------------+----------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by igloo): Someone else had this problem, but upgrading libedit fixed it. We think (but haven't verified) that this Debian patch is what fixes the problem: {{{ 06-fgetln.c-error.diff by Ben Burton Routine fgetln() was behaving incorrectly on error (such as when EOF was reached), which in turn caused infinite memory consumption during read_history(). --- a/glibc-bsd-glue/fgetln.c +++ a/glibc-bsd-glue/fgetln.c @@ -5,9 +5,10 @@ { char *line=NULL; - getline (&line, len, stream); - - (*len)--; /* get rid of the trailing \0, fgetln - does not have it */ - return line; + if (getline (&line, len, stream) >= 0) { + (*len)--; /* get rid of the trailing \0, fgetln + does not have it */ + return line; + } else + return NULL; } }}} Can someone take a look to see if Gentoo's libedit looks buggy please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 07:31:59 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 07:27:40 2008 Subject: [GHC] #2697: bad testsuite results with ghc-6.10.0.20081007 In-Reply-To: <045.c368cc178489a6d371c14b6319d3b743@localhost> References: <045.c368cc178489a6d371c14b6319d3b743@localhost> Message-ID: <054.1903d5cb4a4e68697bfc15eabcca4a90@localhost> #2697: bad testsuite results with ghc-6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by maeder): fixing my CPATH and LD_LIBRARY_PATH on our ppc Mac 10.4 leaves 155 unexpected failures: http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.10.0.20081007-tests.log2.bz2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 08:15:25 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 08:11:07 2008 Subject: [GHC] #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 In-Reply-To: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> References: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> Message-ID: <058.874ec3952ef81ece56f0f6fed81dd4c2@localhost> #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: fixed Keywords: panic | Difficulty: Unknown Testcase: T2693 | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by chak): * testcase: => T2693 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 09:52:33 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 09:49:40 2008 Subject: [GHC] #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 In-Reply-To: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> References: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> Message-ID: <058.a412485c936180274ad545ed04c4a606@localhost> #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: chak Type: merge | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: panic | Difficulty: Unknown Testcase: T2693 | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: closed => reopened * type: bug => merge * resolution: fixed => Comment: Ian pls merge {{{ Tue Oct 21 05:01:07 PDT 2008 Manuel M T Chakravarty * FIX #2693 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 09:53:49 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 09:50:32 2008 Subject: [GHC] #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 In-Reply-To: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> References: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> Message-ID: <058.9f0b3914f173f545c67291f5ca4ed64e@localhost> #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: panic | Difficulty: Unknown Testcase: T2693 | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: reopened => new * owner: chak => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 09:56:34 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 09:52:26 2008 Subject: [GHC] #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint In-Reply-To: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> References: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> Message-ID: <060.7b34f87ff7d4c845941a709b3eb4ee0d@localhost> #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint ------------------------------+--------------------------------------------- Reporter: PVerswyvelen | Owner: chak Type: merge | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: T2688 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: closed => reopened * type: bug => merge * resolution: fixed => Comment: Fixed by {{{ Mon Oct 20 21:42:13 PDT 2008 Manuel M T Chakravarty * FIX #2688 }}} Pls merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 09:56:53 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 09:52:41 2008 Subject: [GHC] #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint In-Reply-To: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> References: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> Message-ID: <060.41a8c5fe5047da8782b193129c3145e9@localhost> #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint ------------------------------+--------------------------------------------- Reporter: PVerswyvelen | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: T2688 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: reopened => new * owner: chak => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 11:17:50 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 11:13:28 2008 Subject: [GHC] #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine Message-ID: <045.73e9a3354e42db349317d7c1c2959ccf@localhost> #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine -----------------------+---------------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.3 | Severity: blocker Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- I'm trying to compile ghc-6.8.3 on an old Red Hat 7.3 system. Using an older ghc-6.2.2 compiler I configure: {{{ > ./configure --with-ghc=/opt/ghc/ghc-6.2.2/bin/ghc --prefix=/opt/ghc/ghc-6.8.3 ... }}} I make: {{{ > make ... /opt/ghc/ghc-6.2.2/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -package unix -c typecheck/TcBinds.lhs -o stage1/typecheck/TcBinds.o -ohi stage1/typecheck/TcBinds.hi typecheck/TcBinds.lhs:523: Couldn't match `BoxyType -> TcM a' against `TcM (HsWrapper, MatchGroup TcId)' Expected type: BoxyType -> TcM a Inferred type: TcM (HsWrapper, MatchGroup TcId) Probable cause: `tcMatchesFun' is applied to too many arguments in the call (tcMatchesFun name inf matches) In the first argument of `tcInfer', namely `(tcMatchesFun name inf matches)' typecheck/TcBinds.lhs:672: Couldn't match `TcM (HsWrapper, MatchGroup TcId)' against `t -> t1' Expected type: TcM (HsWrapper, MatchGroup TcId) Inferred type: t -> t1 Probable cause: `tcMatchesFun' is applied to too many arguments in the call (tcMatchesFun (idName mono_id) inf matches (idType mono_id)) In a 'do' expression: (co_fn, matches') <- tcMatchesFun (idName mono_id) inf matches (idType mono_id) <> make[1]: *** [stage1/typecheck/TcBinds.o] Error 1 make: *** [stage1] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 11:37:00 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 11:32:43 2008 Subject: [GHC] #2719: urk! lookup local fingerprint with -O and TemplateHaskell Message-ID: <045.885acddd657eb454eb7c3cd4aca64934@localhost> #2719: urk! lookup local fingerprint with -O and TemplateHaskell -----------------------+---------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- An interesting feature of this bug is that it goes away when TemplateHaskell is removed (it's cut down from a much larger test case which actually used that) -O is also necessary. ghc -c -O Foo.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.0.20081007 for i386-unknown-mingw32): urk! lookup local fingerprint main:Foo.:CoActionT{tc rj4} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 12:33:04 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 12:28:44 2008 Subject: [GHC] #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) In-Reply-To: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> References: <043.9f62f4970bbaf82fc93c540386fe8f92@localhost> Message-ID: <052.3173f68cb6d99b2c34671552137c0c03@localhost> #2716: ghci uses an enormous amount of memory (recent 6.10 snapshots) ----------------------+----------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by ravi): * status: new => closed * resolution: => invalid Comment: From looking at source, the Gentoo libedit version I was using (dev- libs/libedit-20050930) appears to have the bug. I upgraded to Gentoo's dev-libs/libedit-20061103-r2, but it has the same problem. Applying the referenced patch solved the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 12:38:40 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 12:34:20 2008 Subject: [GHC] #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine In-Reply-To: <045.73e9a3354e42db349317d7c1c2959ccf@localhost> References: <045.73e9a3354e42db349317d7c1c2959ccf@localhost> Message-ID: <054.7fda901910d4830371a93faa5c010f3d@localhost> #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine -----------------------------+---------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: blocker | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------------+---------------------------------------------- Changes (by jputcu): * cc: joris.putcuyps@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 13:01:17 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 12:57:10 2008 Subject: [GHC] #2698: Windows binary distribution pops up README.TXT for the source distribution In-Reply-To: <045.bc598ef2cae0aae707dbc598e8bfe53c@localhost> References: <045.bc598ef2cae0aae707dbc598e8bfe53c@localhost> Message-ID: <054.dd740a44d976d2c03ab62acdc3560fbd@localhost> #2698: Windows binary distribution pops up README.TXT for the source distribution ----------------------+----------------------------------------------------- Reporter: ganesh | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10: {{{ Tue Oct 21 17:25:43 BST 2008 Ian Lynagh * Don't put the README file in the Windows installer; fixes trac #2698 The README file talks about getting and building the sources, which doesn't make sense for the installer. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 15:43:38 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 15:39:17 2008 Subject: [GHC] #2703: Buffer overflow, occasional segfaults when using handles created by Network. In-Reply-To: <043.0b636667312adf746bdfc543d5231d22@localhost> References: <043.0b636667312adf746bdfc543d5231d22@localhost> Message-ID: <052.a703151bbcde0c28bd8ba86418886ca8@localhost> #2703: Buffer overflow, occasional segfaults when using handles created by Network. -------------------------------+-------------------------------------------- Reporter: sclv | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.1 Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 15:44:02 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 15:39:47 2008 Subject: [GHC] #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint In-Reply-To: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> References: <051.59b70bf485ce3dcaf95344ced84c7103@localhost> Message-ID: <060.cef5489ec98f71fc3e14f97e99d7afb4@localhost> #2688: GHC 6.10.0.20081007 hangs instead of giving error about missing type class constraint ------------------------------+--------------------------------------------- Reporter: PVerswyvelen | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2688 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 15:44:34 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 15:40:15 2008 Subject: [GHC] #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 In-Reply-To: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> References: <049.153daf82f6ca41b0d932ecd6447ef274@localhost> Message-ID: <058.eb874d0dd0e4bdb0cbaee069f4fd45d9@localhost> #2693: Type Synonym Family Panic in GHC 6.10.0.20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: fixed Keywords: panic | Difficulty: Unknown Testcase: T2693 | Architecture: x86 Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 18:37:48 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 18:33:25 2008 Subject: [GHC] #2711: haddock contents/index includes hidden modules (broken links) In-Reply-To: <044.fbfe2f60930b12a4a437841b14560394@localhost> References: <044.fbfe2f60930b12a4a437841b14560394@localhost> Message-ID: <053.489ffc5f78f44ac710093ef34c0651a2@localhost> #2711: haddock contents/index includes hidden modules (broken links) ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Mon Oct 20 22:13:24 BST 2008 David Waern * Do not save hidden modules in the .haddock file }}} {{{ Tue Oct 21 20:54:52 BST 2008 David Waern * Do not save hidden modules in the .haddock file (also for ghc >= 6.9) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 21:44:51 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 21:40:28 2008 Subject: [GHC] #2720: eyeball/inline1 still isn't optimised with -fno-method-sharing Message-ID: <041.a872c76a5e9b7b0657aff218eccbf6d8@localhost> #2720: eyeball/inline1 still isn't optimised with -fno-method-sharing -----------------------------------------+---------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------+---------------------------------- Just as a reminder: `eyeball/inline1.hs` isn't optimised properly if `-fno-method-sharing` is set after this patch: {{{ Tue Sep 9 08:50:11 PDT 2008 simonpj@microsoft.com * Important performance wibble to callSiteInline (the n_vals_wanted > 0 thing) }}} This affects DPH code quite a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 21 22:12:52 2008 From: trac at galois.com (GHC) Date: Tue Oct 21 22:08:28 2008 Subject: [GHC] #2721: Newtype deriving doesn't work with type families Message-ID: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> #2721: Newtype deriving doesn't work with type families ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ This assumes `-XTypeFamiles -XGeneralizedNewtypeDeriving`. Example: {{{ class C a where type T a foo :: a -> T a instance C Int where type T Int = Int foo = id newtype N = N Int deriving(C) }}} This happily produces an `instance C N` but no `type instance T N`. It should either (preferably) generate {{{ type instance T N = Int }}} or fail. The example also compiles if `T` is a data family (the `Int` instance needs to be change accordingly). It should probably fail in this case. BTW, this also compiles fine, with rather dramatic consequences: {{{ type family T a class C a where foo :: a -> T a type instance T Int = Int instance C Int where foo = id type instance T N = Double newtype N = N Int deriving(C) }}} I guess this last example is the same bug as `#1496`. I wonder if the deriving clause could generate something like: {{{ instance T Int ~ T N => C Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 22 05:54:51 2008 From: trac at galois.com (GHC) Date: Wed Oct 22 05:50:33 2008 Subject: [GHC] #2719: urk! lookup local fingerprint with -O and TemplateHaskell In-Reply-To: <045.885acddd657eb454eb7c3cd4aca64934@localhost> References: <045.885acddd657eb454eb7c3cd4aca64934@localhost> Message-ID: <054.96964fa91a26d01a638d16edef282b8d@localhost> #2719: urk! lookup local fingerprint with -O and TemplateHaskell ----------------------+----------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Duplicate of #2685, which should be fixed in recent snapshots. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 22 06:06:43 2008 From: trac at galois.com (GHC) Date: Wed Oct 22 06:02:29 2008 Subject: [GHC] #485: AdjustorAsm.S doesn't build on AIX In-Reply-To: <047.348c1b9e6ebc7759d7861925cfd6ccd1@localhost> References: <047.348c1b9e6ebc7759d7861925cfd6ccd1@localhost> Message-ID: <056.2f62d5f22eeac0ae5da1f711b560f008@localhost> #485: AdjustorAsm.S doesn't build on AIX ----------------------+----------------------------------------------------- Reporter: jgoerzen | Owner: nobody Type: bug | Status: assigned Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown/Multiple Os: AIX | ----------------------+----------------------------------------------------- Changes (by CBa): * cc: ich@christoph-bauer.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 22 06:31:45 2008 From: trac at galois.com (GHC) Date: Wed Oct 22 06:27:28 2008 Subject: [GHC] #485: AdjustorAsm.S doesn't build on AIX In-Reply-To: <047.348c1b9e6ebc7759d7861925cfd6ccd1@localhost> References: <047.348c1b9e6ebc7759d7861925cfd6ccd1@localhost> Message-ID: <056.27a8ca0cfbb69a59eef264db15b96317@localhost> #485: AdjustorAsm.S doesn't build on AIX ----------------------+----------------------------------------------------- Reporter: jgoerzen | Owner: nobody Type: bug | Status: assigned Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown/Multiple Os: AIX | ----------------------+----------------------------------------------------- Comment (by CBa): thanks wolfgang for the recipe. I compared AdjustorAsm.S with an assembler file from OCaml. And here are the indrigients for the recipe: .text => .csect .text[PR] adjustorCode: => .adjustorCode subf => subfc b 2f => b L..2 1: => L..1: 2: => L..2: bdnz 1b => bdnz L..1 Then the compilation works. I'm uncertain, how to do the ifdefs so, that Audrey Tang isn't affected... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 22 09:09:15 2008 From: trac at galois.com (GHC) Date: Wed Oct 22 09:04:52 2008 Subject: [GHC] #2668: Standalone deriving doesn't do newtype deriving properly In-Reply-To: <044.57c98c379e66d168145ce5a2a4f71693@localhost> References: <044.57c98c379e66d168145ce5a2a4f71693@localhost> Message-ID: <053.287bce02d7b128ebfa45aa78e435afb2@localhost> #2668: Standalone deriving doesn't do newtype deriving properly ------------------------------+--------------------------------------------- Reporter: ryani | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: Fixed by {{{ Tue Oct 21 07:29:22 PDT 2008 simonpj@microsoft.com * Fix Trac #2668, and refactor TcDeriv }}} Pls merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 22 10:56:43 2008 From: trac at galois.com (GHC) Date: Wed Oct 22 10:52:47 2008 Subject: [GHC] #2714: No match in record selector Var.tcTyVarDetails In-Reply-To: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> References: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> Message-ID: <054.8912f41b71f019090c59672d54d1c510@localhost> #2714: No match in record selector Var.tcTyVarDetails --------------------------------------------------+------------------------- Reporter: morrow | Owner: merge Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: Var, tcTyVarDetails, record selector | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------------------+------------------------- Changes (by simonpj): * owner: => merge * difficulty: => Unknown * type: bug => merge Comment: Thanks for the report. It's a small bug in the new code that deals with impredicativity. Fixed by {{{ Wed Oct 22 15:51:38 GMT Daylight Time 2008 simonpj@microsoft.com * Fix Trac #2714 (a minor wibble) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 22 11:05:00 2008 From: trac at galois.com (GHC) Date: Wed Oct 22 11:00:41 2008 Subject: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019 Message-ID: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> #2722: < when compiling with -O option with ghc-6.10.0.20081019 ----------------------------------+----------------------------------------- Reporter: uwe | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: Optimization Loop | Testcase: Architecture: x86 | Os: Linux ----------------------------------+----------------------------------------- When trying to compile HXT with ghc-6.10 rc1 all examples, even the simplest ones give the following result. Here is an example: {{{ theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> ./HXmlParser example1.xml HXmlParser: <> }}} this only occurs, when compiling with -O (or -O2). When compiling whithout any optimizaions, the programs run as expected Here is a more complete log of one example The running example without -O {{{ theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.0.20081019 theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> ghc-pkg list /home/theo/lib/ghc-6.10.0.20081019/./package.conf: Cabal-1.6.0.1, HUnit-1.2.0.2, QuickCheck-1.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, bytestring-0.9.1.4, containers-0.2.0.0, curl-1.3.2.1, directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), filepath-1.1.0.1, (ghc-6.10.0.20081019), ghc-prim-0.1.0.0, haddock-2.2.2, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.2, hxt-8.2.0, integer-0.1.0.0, mtl-1.1.0.2, network-2.2.0.0, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.0.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.1, syb-0.1.0.0, tagsoup-0.6, template-haskell-2.3.0.0, time-1.1.2.2, unix-2.3.1.0, xhtml-3000.2.0.1 theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> find ../../../src -name '*.hi' | xargs rm -f theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> make local GHCFLAGS=-Wall ghc --make -o ./HXmlParser -Wall -fglasgow-exts -ignore-package hxt -i../../../src ./HXmlParser.hs [ 1 of 112] Compiling Text.XML.HXT.XPath.XPathKeywords ( ../../../src/Text/XML/HXT/XPath/XPathKeywords.hs, ../../../src/Text/XML/HXT/XPath/XPathKeywords.o ) [ 2 of 112] Compiling Text.XML.HXT.IO.GetFILE ( ../../../src/Text/XML/HXT/IO/GetFILE.hs, ../../../src/Text/XML/HXT/IO/GetFILE.o ) [ 3 of 112] Compiling Text.XML.HXT.DTDValidation.RE ( ../../../src/Text/XML/HXT/DTDValidation/RE.hs, ../../../src/Text/XML/HXT/DTDValidation/RE.o ) ... [111 of 112] Compiling Text.XML.HXT.Arrow ( ../../../src/Text/XML/HXT/Arrow.hs, ../../../src/Text/XML/HXT/Arrow.o ) [112 of 112] Compiling Main ( HXmlParser.hs, HXmlParser.o ) Linking ./HXmlParser ... theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> ./HXmlParser example1.xml hello world ???? test }}} The same with -O {{{ theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> find ../../../src -name '*.hi' | xargs rm -f theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> make clean rm -f ./HXmlParser *.o *.hi theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> make local GHCFLAGS="-Wall -O" ghc --make -o ./HXmlParser -Wall -O -fglasgow-exts -ignore-package hxt -i../../../src ./HXmlParser.hs [ 1 of 112] Compiling Text.XML.HXT.XPath.XPathKeywords ( ../../../src/Text/XML/HXT/XPath/XPathKeywords.hs, ../../../src/Text/XML/HXT/XPath/XPathKeywords.o ) [ 2 of 112] Compiling Text.XML.HXT.IO.GetFILE ( ../../../src/Text/XML/HXT/IO/GetFILE.hs, ../../../src/Text/XML/HXT/IO/GetFILE.o ) [ 3 of 112] Compiling Text.XML.HXT.DTDValidation.RE ( ../../../src/Text/XML/HXT/DTDValidation/RE.hs, ../../../src/Text/XML/HXT/DTDValidation/RE.o ) [ 4 of 112] Compiling Text.XML.HXT.RelaxNG.Unicode.Blocks ( ../../../src/Text/XML/HXT/RelaxNG/Unicode/Blocks.hs, ../../../src/Text/XML/HXT/RelaxNG/Unicode/Blocks.o ) ... [111 of 112] Compiling Text.XML.HXT.Arrow ( ../../../src/Text/XML/HXT/Arrow.hs, ../../../src/Text/XML/HXT/Arrow.o ) [112 of 112] Compiling Main ( HXmlParser.hs, HXmlParser.o ) Linking ./HXmlParser ... theo@brett:~/haskell/hxt-ghc10/examples/arrows/hparser> ./HXmlParser example1.xml HXmlParser: <> }}} The only difference is the -O. My guess is, that there could be problems with the overloaded version of id and . (function comp.). This is used in HXT because of various arrow types. In the example going wrong, there is a list arrow involved, that manages a state and runs in the IO monad. It's rather hard to strip down this test case to a smaller example, because I've no idea where to search for this loop. If neccessary I can prepare a tar archive with all sources needed to reproduce this error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 22 11:18:50 2008 From: trac at galois.com (GHC) Date: Wed Oct 22 11:14:25 2008 Subject: [GHC] #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 In-Reply-To: <049.253b91b6ac2808a333ea293682ed290c@localhost> References: <049.253b91b6ac2808a333ea293682ed290c@localhost> Message-ID: <058.de9ee8ff1772d11e6b36664b1aa0ec3c@localhost> #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Hmm. I'm not sure what 'worked fine' means. I think that with the declaration splice un-commented, GHC should probably report an error "Fixity declaration without accompanying definition" or something. Remember that GHC renames and typechecks all the code up to and including the first declaration splice; then runs the splice, and then renames and typechecks the result of the splice, plus all the code that follows up to and including the next splice. (Reason: the first splice might bring new stuff into scope that is needed to make sense of the stuff that follows the splice.) To be concrete, what would you expect to happen here? {{{ module Fixity where class MyClass a where (.*.) :: a -> a -> a main = putStrLn "hi" $(f (1 .*. 2 * 3) ) infixr 3 .*. }}} That is, what fixity does `(.*.)` have in the code for the decl splice? Remember, at this point GHC hasn't "seen" the declarations below. I don't like the idea that an operator might have different fixities in different parts of the code. So I assert that the bug is that you don't get an error message, not that the fixity is omitted from the interface file. I'll add that error check -- but first I want to check that this makes sense to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 22 14:52:47 2008 From: trac at galois.com (GHC) Date: Wed Oct 22 14:48:23 2008 Subject: [GHC] #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 In-Reply-To: <049.253b91b6ac2808a333ea293682ed290c@localhost> References: <049.253b91b6ac2808a333ea293682ed290c@localhost> Message-ID: <058.52df9489d23bdc6004a273cff522c180@localhost> #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by BenMoseley): I see - I guess that makes sense. In the original code (which I don't have access to right now) I'm pretty sure the splice was separating the "infixr" from the class definition ... so I guess it should really never have compiled. (By "worked fine" I mean that the module compiled cleanly and that the resulting ".hi" file did include the "infixr 3" specification so that other parts of the code - which required that fixity specification to compile successfully - had no problem). Incidentally, I worked around this "issue" by relocating the fixity declaration - which sounds like the correct thing to do anyway given your explanation. I agree that an error message sounds like the right fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 23 08:00:36 2008 From: trac at galois.com (GHC) Date: Thu Oct 23 07:56:10 2008 Subject: [GHC] #2668: Standalone deriving doesn't do newtype deriving properly In-Reply-To: <044.57c98c379e66d168145ce5a2a4f71693@localhost> References: <044.57c98c379e66d168145ce5a2a4f71693@localhost> Message-ID: <053.ee37fa9a6ae91adf186bfa059bbf0462@localhost> #2668: Standalone deriving doesn't do newtype deriving properly ------------------------------+--------------------------------------------- Reporter: ryani | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 23 08:59:37 2008 From: trac at galois.com (GHC) Date: Thu Oct 23 08:55:10 2008 Subject: [GHC] #2682: Keep going after failed search for module in current directory In-Reply-To: <042.3ab3a08a92cd2130db77f37efdac62b0@localhost> References: <042.3ab3a08a92cd2130db77f37efdac62b0@localhost> Message-ID: <051.62124b48b3c2007ea863efffc8728e63@localhost> #2682: Keep going after failed search for module in current directory ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by mpalka): At least the message should be improved. It was very confusing for me before I realized that I need to cd out of the package tree. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 23 09:00:01 2008 From: trac at galois.com (GHC) Date: Thu Oct 23 08:55:34 2008 Subject: [GHC] #2682: Keep going after failed search for module in current directory In-Reply-To: <042.3ab3a08a92cd2130db77f37efdac62b0@localhost> References: <042.3ab3a08a92cd2130db77f37efdac62b0@localhost> Message-ID: <051.a3bb3df78e81b92cddf6654f9285411e@localhost> #2682: Keep going after failed search for module in current directory ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by mpalka): * cc: michal.palka@poczta.fm (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 23 09:13:44 2008 From: trac at galois.com (GHC) Date: Thu Oct 23 09:09:15 2008 Subject: [GHC] #2715: Equality constraint in superclass causes panic: applyTypeToArgs In-Reply-To: <047.797aaec011bad118fea0580e1c0ce283@localhost> References: <047.797aaec011bad118fea0580e1c0ce283@localhost> Message-ID: <056.05e1e6bbabacd5cf1f46f1baeeb0fda6@localhost> #2715: Equality constraint in superclass causes panic: applyTypeToArgs -------------------------------------+-------------------------------------- Reporter: rodprice | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Comment (by igloo): See also: #2686 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 23 13:10:02 2008 From: trac at galois.com (GHC) Date: Thu Oct 23 13:05:35 2008 Subject: [GHC] #2723: Unnecessary warning for record wildcards Message-ID: <044.5ab60ea4e40213824e6aecfc247bc68c@localhost> #2723: Unnecessary warning for record wildcards ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ When compiling a file with record wildcards, -Wall produces a warning about shadowed bindings. Since the presence of a wildcard indicates that the shadowing was intentional, this warning seems unnecessary. I reproduced this with both 6.8.3 and 6.10.0.20081007: {{{ {-# LANGUAGE RecordWildCards #-} module WildCard where data Record = Record {field1 :: Int, field2 :: Double} test :: Record test = let field1 = 10 field2 = 10.0 in Record {..} }}} {{{ $ ghc --make -Wall WildCard.hs [1 of 1] Compiling WildCard ( WildCard.hs, WildCard.o ) WildCard.hs:8:4: Warning: This binding for `field1' shadows the existing binding defined at WildCard.hs:4:22 In the binding group for: field1, field2 WildCard.hs:9:4: Warning: This binding for `field2' shadows the existing binding defined at WildCard.hs:4:37 In the binding group for: field1, field2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 24 08:23:05 2008 From: trac at galois.com (GHC) Date: Fri Oct 24 08:18:35 2008 Subject: [GHC] #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib In-Reply-To: <043.cf6c9356908d84d15cb72785d970ada9@localhost> References: <043.cf6c9356908d84d15cb72785d970ada9@localhost> Message-ID: <052.8d2132c6b62cbc17b5f398a12bd4d473@localhost> #2683: Boxy-type ASSERT failure in 6.10: panic in xmonad-contrib ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: almost certainly not arch/os specific -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 24 10:24:53 2008 From: trac at galois.com (GHC) Date: Fri Oct 24 10:20:23 2008 Subject: [GHC] #2063: Breackage on OpenBSD due to mmap remap In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.8718062f4faa8c83240221cc3462485d@localhost> #2063: Breackage on OpenBSD due to mmap remap ----------------------------+----------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: x86_64 (amd64) Os: OpenBSD | ----------------------------+----------------------------------------------- Changes (by simonmar): * architecture: Unknown/Multiple => x86_64 (amd64) Comment: This is amd64 only. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Oct 25 15:39:16 2008 From: trac at galois.com (GHC) Date: Sat Oct 25 15:34:45 2008 Subject: [GHC] #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack Message-ID: <044.2d874f0fab562627c6bb887ff848f8fd@localhost> #2724: foreign functions called from optimized Haskell code receive non-empty fpu stack -----------------------+---------------------------------------------------- Reporter: aruiz | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- It has been observed that wrong NaN's are produced by foreign functions in complex and not easily reproducible situations: http://hackage.haskell.org/trac/ghc/ticket/1944 http://thread.gmane.org/gmane.comp.lang.haskell.cafe/31675 I also had this problem in the hmatrix library. But now it can be easily reproduced and traced to a particular point in foreign C code, where we observe that the product of two innocent looking doubles evaluates to NaN. Using gdb we find that the fpu state received by the foreign function, which is normally like this: {{{ (gdb) info float R7: Empty 0x3ffcaaf881cab3b3b800 R6: Empty 0x3fff8000000000000000 R5: Empty 0x00000000000000000000 R4: Empty 0x3fff8000000000000000 R3: Empty 0xbffb88bf61ae9d22828a R2: Empty 0x80000000000000000000 R1: Empty 0x3ffe86490c2ce3303000 =>R0: Empty 0xbffcfb4ceea7f26db95c Status Word: 0x4032 DE UE PE C3 TOP: 0 Control Word: 0x037f IM DM ZM OM UM PM PC: Extended Precision (64-bits) RC: Round to nearest Tag Word: 0xffff Instruction Pointer: 0x73:0xb7e284b0 Operand Pointer: 0x7b:0xb6e7e1f8 Opcode: 0xdd1a }}} has some "valid" data in the calls which produce the NaN: {{{ (gdb) info float R7: Empty 0x3fcb9e8b62d59977a000 R6: Empty 0x3fcabc5cf9a9be1cd800 R5: Empty 0x401f8000000000000000 R4: Empty 0x401e9b97f4a800000000 R3: Empty 0xbffcaaf881cab3b3b800 R2: Empty 0x00000000000000000000 R1: Valid 0x3fdddbe6fecebdedd800 +1.000000000000000036e-10 =>R0: Valid 0x3fcb9e8b62d59977a000 +2.750308259657520213e-16 Status Word: 0x0132 DE UE PE C0 TOP: 0 Control Word: 0x037f IM DM ZM OM UM PM PC: Extended Precision (64-bits) RC: Round to nearest Tag Word: 0xfff0 Instruction Pointer: 0x73:0x08063cb3 Operand Pointer: 0x7b:0x00000000 Opcode: 0xd8da }}} The attached tarball showbug.tar.gz contains a modified version of the library which exposes the problem. Detailed information can be found in the enclosed file README_BUG. A simple workaround is calling asm("finit") before any work is done in the foreign functions. However, there is strong evidence that the problem is caused in the Haskell side because asm("finit") does not avoid the problem if called '''after''' each foreign function. See README_BUG for details. In any case, I also attach a version (showbug2) without lapack (please try the other one first). It only happens with '''optimized -fasm''' Haskell code, and with certain foreign functions. Interestingly, some implementations (e.g. Intel's MKL) don't produce any NaN, so at first it could be thought that there was some subtle bug in some versions of blas/lapack. But this new result about the fpu state suggests that this is probably not the case. The wrong NaN's appear in all the 32bit machines that I have tested (older Pentium, newer Dual Core, and even on an ultraportable with Atom, and with different Ubuntu versions, Fedora, Arch, and Debian). Probably it also happens in Windows, but I have not tested it recently. I experienced the problem with ghc 6.8.x, 6.10-rc, (and probably 6.6). I cannot reproduce the problem on 64bit systems (but I have only tested one single 64bit machine) Finally, I hope that this problem is not caused by some error in the hmatrix library... Alberto Ruiz -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 26 00:50:47 2008 From: trac at galois.com (GHC) Date: Sun Oct 26 00:46:10 2008 Subject: [GHC] #1291: Binary Solaris build fails on Solaris 9 In-Reply-To: <044.da39aece29339a0f32ded51c36797f3d@localhost> References: <044.da39aece29339a0f32ded51c36797f3d@localhost> Message-ID: <053.3574e411c1337729b325e3f3a1da2e4f@localhost> #1291: Binary Solaris build fails on Solaris 9 --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: _|_ Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by guest): * status: closed => reopened * resolution: invalid => Comment: Can you please change the website/docs to reflect this? Either: * package is tested and known to work on solaris 10 (this is basically libm.so.2 was introduced to the general public) and remove the reference to solaris 8 * add the above symlink magic for libm.so.1 and libm.so.2 to either the webpage or the install instructions Many people reading it will assume it should work for them on solaris 8 and 9 (99%+ of things that work on 8 will work out of the box on 9) -- this is more of a website bug than a compiler bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Oct 26 02:02:07 2008 From: trac at galois.com (GHC) Date: Sun Oct 26 01:57:32 2008 Subject: [GHC] #1291: Binary Solaris build fails on Solaris 9 In-Reply-To: <044.da39aece29339a0f32ded51c36797f3d@localhost> References: <044.da39aece29339a0f32ded51c36797f3d@localhost> Message-ID: <053.3ac9998f33b384f5c1d8e6d01b1a6283@localhost> #1291: Binary Solaris build fails on Solaris 9 --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: _|_ Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by guest): sorry, this is in reference to the current page for 6.8.3, which says {{{ This is a binary distribution for Solaris, known to work on versions 8 and 10 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Sun Oct 26 12:42:14 2008 From: conal at conal.net (Conal Elliott) Date: Sun Oct 26 12:37:37 2008 Subject: TypeCompose Patch In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D76A78B6C@EA-EXMSG-C334.europe.corp.microsoft.com> References: <5154.24.69.170.39.1222276110.squirrel@squishy.internetofdeath.com> <5614.24.69.170.39.1222291451.squirrel@squishy.internetofdeath.com> <6268.24.69.170.39.1222292558.squirrel@squishy.internetofdeath.com> <20080925005001.GC18545@gmx.de> <638ABD0A29C8884A91BC5FB5C349B1C32D766E2F95@EA-EXMSG-C334.europe.corp.microsoft.com> <638ABD0A29C8884A91BC5FB5C349B1C32D76A78B6C@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Thanks for the follow-up. Indeed the bug is fixed in 6.10 and following. About the linear map comment, I was referring to the same bug (now fixed), not a different one. I described the linear maps implementation in two recent blog posts (http://conal.net/blog). - Conal On Mon, Oct 13, 2008 at 5:31 AM, Simon Peyton-Jones wrote: > I believe it's fixed in HEAD and 6.10; I recall Manuel saying he'd done > it, the same day I told him. (I thought I'd created a Trac ticket for it, > but I don't seem to have done so.) (Worth noting for future: if you create > a ticket you can follow the history more easily.) > > > > As to the "my linear map implementation, but not when it tickles a ghc bug > for me and for readers", do we have a Trac ticket for that? I don't know > what the bug is, nor whether it's fixed. > > > > Simon > > > > *From:* conal.elliott@gmail.com [mailto:conal.elliott@gmail.com] *On > Behalf Of *Conal Elliott > *Sent:* 12 October 2008 06:36 > *To:* Simon Peyton-Jones > *Cc:* glasgow-haskell-bugs@haskell.org > *Subject:* Re: TypeCompose Patch > > > > What's the status of this bug? I'd like to know when it's safe to upgrade > to a new ghc. Also, I want to blog about my linear map implementation, but > not when it tickles a ghc bug for me and for readers. > > Thanks, - Conal > > 2008/9/25 Simon Peyton-Jones > > Conal, Marc > > This is definitely a bug in the new equality-solving mechanism. I can > reproduce it readily. I'll discuss it with Manuel tomorrow and get back to > you. Thanks for finding it! > > Simon > > > | -----Original Message----- > | From: glasgow-haskell-bugs-bounces@haskell.org [mailto: > glasgow-haskell-bugs- > | bounces@haskell.org] On Behalf Of Marc Weber > | Sent: 25 September 2008 01:50 > | To: glasgow-haskell-bugs@haskell.org > | Subject: Re: TypeCompose Patch > | > | On Wed, Sep 24, 2008 at 02:55:01PM -0700, Conal Elliott wrote: > | > Eep! That code (which uses type classes) fails to compile under > 6.8.3 > | but > | > does compile under 6.9. Looks like 6.10 broke something. > | > > | > Can anyone else check whether vector-space build or breaks under > 6.10? > | > The repo is > | > > | > [1]http://code.haskell.org/vector-space/ > | > | src/Data/LinearMap.hs|37 col 21 error| > | || Couldn't match expected type `t' against inferred type `Basis u' > | || In the second argument of `(.)', namely `basisValue' > | || In the first argument of `trie', namely `(f . basisValue)' > | || In the expression: trie (f . basisValue) > | > | Hi Conal, I'm getting the error above (current ghc from darcs) > | If you want I can give you an ssh account where this ghc version is > | installed within the next days. > | > | I also had to add a -fglasgow-exts to a MemoTrie file.. > | (Not sure which is the correct language extension which was missing) > | > | Sincerly > | Marc Weber > | _______________________________________________ > | Glasgow-haskell-bugs mailing list > | Glasgow-haskell-bugs@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20081026/8a12e9a2/attachment-0001.htm From trac at galois.com Sun Oct 26 15:41:14 2008 From: trac at galois.com (GHC) Date: Sun Oct 26 15:36:35 2008 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs Message-ID: <046.d67fe0f29d3ab9719210cf02d0142851@localhost> #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs ---------------------------------+------------------------------------------ Reporter: clemens | Owner: clemens Type: bug | Status: new Priority: normal | Component: Compiler (NCG) Version: 6.11 | Severity: minor Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Remove the hack around Line 3914 labeled with: -- HACK: On x86_64 binutils<2.17 is only able to generate PC32 -- relocations, hence we only get 32-bit offsets in the jump -- table. As these offsets are always negative we need to properly -- sign extend them to 64-bit. This hack should be removed in -- conjunction with the hack in PprMach.hs/pprDataItem once -- binutils 2.17 is standard. This bug is intended for house keeping. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 05:54:48 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 05:50:15 2008 Subject: [GHC] #1291: Binary Solaris build fails on Solaris 9 In-Reply-To: <044.da39aece29339a0f32ded51c36797f3d@localhost> References: <044.da39aece29339a0f32ded51c36797f3d@localhost> Message-ID: <053.56d998627151507e630a97bcba3d3155@localhost> #1291: Binary Solaris build fails on Solaris 9 --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: _|_ Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): if someone tells me how to build ghc under Solaris 8 using libm.so.1 only, I could try it (for the next release). I used to get a mere link error for the stage2 compiler without libm.so.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 08:16:34 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 08:11:53 2008 Subject: [GHC] #2701: Cannot derive Data for structures containing unboxed values In-Reply-To: <053.4e805d871d5b4c042cff7a15f7231353@localhost> References: <053.4e805d871d5b4c042cff7a15f7231353@localhost> Message-ID: <062.4852b6c906a8d8c2394fe18b0168f93e@localhost> #2701: Cannot derive Data for structures containing unboxed values ----------------------------------------+----------------------------------- Reporter: batterseapower | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2701 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T2701 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Good point. Fixed by {{{ Sat Oct 25 18:12:11 GMT Daylight Time 2008 simonpj@microsoft.com * Fix Trac #2701: make deriving check better for unlifted args }}} Please merge. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 08:19:43 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 08:15:02 2008 Subject: [GHC] #2700: Template Haskell pretty printer arrow always associates right In-Reply-To: <047.b71a33f0f71e965d047800e7daaf440d@localhost> References: <047.b71a33f0f71e965d047800e7daaf440d@localhost> Message-ID: <056.1870a3d95472d15acb4266029b937a5e@localhost> #2700: Template Haskell pretty printer arrow always associates right ---------------------------------------------+------------------------------ Reporter: aprocter | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: Keywords: th pprint pretty print template | Difficulty: Unknown Testcase: th/T2700 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by simonpj): * testcase: => th/T2700 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Excellent point. Fixed by this patch to the `template-haskell` library {{{ Sat Oct 25 17:44:28 GMT Daylight Time 2008 simonpj@microsoft.com * Fix Trac #2700: pretty-printing of types }}} Please merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 09:16:48 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 09:12:14 2008 Subject: [GHC] #1291: Binary Solaris build fails on Solaris 9 In-Reply-To: <044.da39aece29339a0f32ded51c36797f3d@localhost> References: <044.da39aece29339a0f32ded51c36797f3d@localhost> Message-ID: <053.234a46807939c3528e4d6b03612fc249@localhost> #1291: Binary Solaris build fails on Solaris 9 --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Build System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: I've added a link to this ticket from the 6.8.3 download blurb. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 10:20:28 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 10:15:47 2008 Subject: [GHC] #2726: getAddrInfo and addrFamily not in scope on Windows GHC 6.8 Message-ID: <055.2cef317f10a8954736a4828068318f0d@localhost> #2726: getAddrInfo and addrFamily not in scope on Windows GHC 6.8 ---------------------------------+------------------------------------------ Reporter: speaker2machines | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: netowrk | Testcase: Architecture: x86 | Os: Windows ---------------------------------+------------------------------------------ import Network.Socket ... getAddrInfo ... addrFamily -- gives me not in scope on Windows. The same code works on Unix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 12:10:53 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 12:06:12 2008 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.5eb4e12dd3681f8748859a6a1f1c3440@localhost> #2699: broken pipe errors are too noisy ------------------------------+--------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Would it be best to just keep the errno in the value thrown? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 12:11:42 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 12:07:00 2008 Subject: [GHC] #2700: Template Haskell pretty printer arrow always associates right In-Reply-To: <047.b71a33f0f71e965d047800e7daaf440d@localhost> References: <047.b71a33f0f71e965d047800e7daaf440d@localhost> Message-ID: <056.68649eeb2343394ca44ff36c8bef1c41@localhost> #2700: Template Haskell pretty printer arrow always associates right ---------------------------------------------+------------------------------ Reporter: aprocter | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: Keywords: th pprint pretty print template | Difficulty: Unknown Testcase: th/T2700 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * milestone: => 6.10.1 Old description: > When I run a Template Haskell-generated tysig declaration through pprint, > the associativity for -> comes out incorrectly, e.g.: > > sigD (mkName "foo") [t|(Int -> Bool) -> Bool|] > > renders as: > > foo :: GHC.Base.Int -> GHC.Base.Bool -> GHC.Base.Bool > > (note that it's dropping the parens, associating right instead of left) New description: When I run a Template Haskell-generated tysig declaration through pprint, the associativity for -> comes out incorrectly, e.g.: {{{ sigD (mkName "foo") [t|(Int -> Bool) -> Bool|] }}} renders as: {{{ foo :: GHC.Base.Int -> GHC.Base.Bool -> GHC.Base.Bool }}} (note that it's dropping the parens, associating right instead of left) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 12:12:02 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 12:07:22 2008 Subject: [GHC] #2701: Cannot derive Data for structures containing unboxed values In-Reply-To: <053.4e805d871d5b4c042cff7a15f7231353@localhost> References: <053.4e805d871d5b4c042cff7a15f7231353@localhost> Message-ID: <062.8d61f442d68525a29e3dcffe86068fb1@localhost> #2701: Cannot derive Data for structures containing unboxed values ----------------------------------------+----------------------------------- Reporter: batterseapower | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2701 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 12:36:19 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 12:31:38 2008 Subject: [GHC] #2707: GHCi reports "exitWith ExitSuccess" as an exception In-Reply-To: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> References: <044.f3a0f3d60a218f870448ee9cb31e4ba6@localhost> Message-ID: <053.632a296db57a2e2f7dbf3534ba263192@localhost> #2707: GHCi reports "exitWith ExitSuccess" as an exception ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: I agree. It might be useful to the user to know that the program explicitly exited rather than just finishing, so I think that we should leave the behaviour as it is. If anyone feels strongly that this is the wrong thing to do, then I suggest bringing it up on the glasgow-haskell- users mailing list where more people will see it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 12:48:53 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 12:44:11 2008 Subject: [GHC] #2709: System.Directory.doesDirectoryExist "\\" is False on Windows In-Reply-To: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> References: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> Message-ID: <056.b4dbf98355067d42e18138a60d09547d@localhost> #2709: System.Directory.doesDirectoryExist "\\" is False on Windows ---------------------------------+------------------------------------------ Reporter: Deewiant | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Windows | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 Comment: I think this is because of these FilePath behaviour changes: 6.8.2: {{{ Prelude System.FilePath.Windows> isDrive "\\" True Prelude System.FilePath.Windows> dropTrailingPathSeparator "\\" "\\" }}} 6.10: {{{ Prelude System.FilePath.Windows> isDrive "\\" False Prelude System.FilePath.Windows> dropTrailingPathSeparator "\\" "" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 12:50:11 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 12:45:30 2008 Subject: [GHC] #2710: -main-is flag in {-# OPTIONS #-} pragma not fully supported In-Reply-To: <049.221c5dae52503c4c900cfb790e2e9425@localhost> References: <049.221c5dae52503c4c900cfb790e2e9425@localhost> Message-ID: <058.25bc1ac59a0e40012530341b73631e1e@localhost> #2710: -main-is flag in {-# OPTIONS #-} pragma not fully supported ------------------------------+--------------------------------------------- Reporter: Stephan202 | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: -main-is ghc | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 12:54:15 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 12:49:35 2008 Subject: [GHC] #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 In-Reply-To: <049.253b91b6ac2808a333ea293682ed290c@localhost> References: <049.253b91b6ac2808a333ea293682ed290c@localhost> Message-ID: <058.e6db703ee6a28fe47c0bee0af0c7c7c1@localhost> #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 13:14:09 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 13:10:06 2008 Subject: [GHC] #2714: No match in record selector Var.tcTyVarDetails In-Reply-To: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> References: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> Message-ID: <054.ccd191c4d5980b4df86b650715727a2d@localhost> #2714: No match in record selector Var.tcTyVarDetails --------------------------------------------------+------------------------- Reporter: morrow | Owner: merge Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: Var, tcTyVarDetails, record selector | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------------------+------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 13:55:30 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 13:51:06 2008 Subject: [GHC] #2717: Add nubWith, nubOrd In-Reply-To: <050.81576ece7ea2f3fe706671e03fa58430@localhost> References: <050.81576ece7ea2f3fe706671e03fa58430@localhost> Message-ID: <059.c5521980c0a88dd46c79bb8b02871bf6@localhost> #2717: Add nubWith, nubOrd ------------------------------+--------------------------------------------- Reporter: Bart Massey | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 15:17:00 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 15:12:22 2008 Subject: [GHC] #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine In-Reply-To: <045.73e9a3354e42db349317d7c1c2959ccf@localhost> References: <045.73e9a3354e42db349317d7c1c2959ccf@localhost> Message-ID: <054.0bb1aa55715ae539ff24ecdca0fd727b@localhost> #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine --------------------------+------------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: blocker | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Only >= 6.4.2 is supported for building 6.8.3, sorry. You should be able to build that with 6.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 15:17:12 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 15:12:30 2008 Subject: [GHC] #2720: eyeball/inline1 still isn't optimised with -fno-method-sharing In-Reply-To: <041.a872c76a5e9b7b0657aff218eccbf6d8@localhost> References: <041.a872c76a5e9b7b0657aff218eccbf6d8@localhost> Message-ID: <050.55b2fe629c99cac82b121f6405324bdd@localhost> #2720: eyeball/inline1 still isn't optimised with -fno-method-sharing --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 15:17:56 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 15:13:20 2008 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> Message-ID: <050.ac82e73f11ee0dc5ce49ceb63be5a1c5@localhost> #2721: Newtype deriving doesn't work with type families ------------------------------+--------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 15:22:01 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 15:17:28 2008 Subject: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019 In-Reply-To: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> References: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> Message-ID: <051.33ac24de562b617026727840175a065e@localhost> #2722: < when compiling with -O option with ghc-6.10.0.20081019 -------------------------------+-------------------------------------------- Reporter: uwe | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: Optimization Loop | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 Comment: A tar archive would be very useful, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 15:55:55 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 15:51:16 2008 Subject: [GHC] #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine In-Reply-To: <045.73e9a3354e42db349317d7c1c2959ccf@localhost> References: <045.73e9a3354e42db349317d7c1c2959ccf@localhost> Message-ID: <054.cf320d197119027badd47185cbc0346d@localhost> #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine --------------------------+------------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: blocker | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Comment (by jputcu): Two notes on that: 1) At the bottom of http://www.haskell.org/ghc/download_ghc_683.html, version 6.0 is mentioned as a requirement, this should then be corrected. 2) Can't the configure script be used to check correct versions of ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 18:32:51 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 18:28:09 2008 Subject: [GHC] #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 In-Reply-To: <049.253b91b6ac2808a333ea293682ed290c@localhost> References: <049.253b91b6ac2808a333ea293682ed290c@localhost> Message-ID: <058.79773ba0915a628f44a895af15cf7188@localhost> #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T2713 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * testcase: => th/T2713 * owner: => igloo * type: bug => merge Comment: OK. Fixed by {{{ Mon Oct 27 22:27:38 GMT Standard Time 2008 simonpj@microsoft.com * Fix Trac #2713: refactor and tidy up renaming of fixity decls }}} Pls merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 18:51:46 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 18:47:02 2008 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@localhost> References: <046.d67fe0f29d3ab9719210cf02d0142851@localhost> Message-ID: <055.cbb87adf8e24ede7d5d115b11ea942af@localhost> #2725: Remove Hack in compiler/nativeGen/MachCodeGen.hs ------------------------------+--------------------------------------------- Reporter: clemens | Owner: clemens Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Old description: > Remove the hack around Line 3914 labeled with: > > -- HACK: On x86_64 binutils<2.17 is only able to generate PC32 > -- relocations, hence we only get 32-bit offsets in the jump > -- table. As these offsets are always negative we need to properly > -- sign extend them to 64-bit. This hack should be removed in > -- conjunction with the hack in PprMach.hs/pprDataItem once > -- binutils 2.17 is standard. > > This bug is intended for house keeping. New description: Remove the hack around Line 3914 labeled with: {{{ -- HACK: On x86_64 binutils<2.17 is only able to generate PC32 -- relocations, hence we only get 32-bit offsets in the jump -- table. As these offsets are always negative we need to properly -- sign extend them to 64-bit. This hack should be removed in -- conjunction with the hack in PprMach.hs/pprDataItem once -- binutils 2.17 is standard. }}} This bug is intended for house keeping. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 18:53:05 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 18:48:23 2008 Subject: [GHC] #2723: Unnecessary warning for record wildcards In-Reply-To: <044.5ab60ea4e40213824e6aecfc247bc68c@localhost> References: <044.5ab60ea4e40213824e6aecfc247bc68c@localhost> Message-ID: <053.ac267e283af2c0691c76519a9a382139@localhost> #2723: Unnecessary warning for record wildcards ------------------------------+--------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 20:38:21 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 20:33:39 2008 Subject: [GHC] #2727: DiffArray performance unusable for advertized purpose Message-ID: <044.19ebac4c441c1f8e8ea00498a3c1e235@localhost> #2727: DiffArray performance unusable for advertized purpose -----------------------------------------+---------------------------------- Reporter: claus | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: libraries (other) Version: 6.11 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------+---------------------------------- (cf. this [http://www.haskell.org/pipermail/glasgow-haskell- users/2008-October/015851.html ghc-users thread]) `Data.Array.Diff.DiffArray` is unusably slow. Sometimes even `Data.Array.Array` is faster in single-threaded use, defeating the purpose. The attached code tries to demonstrate the issue, if I got the single-threadedness via `$!` right (default compilation `ghc --make SlowDiffArray.hs` gives `Array`, build with `-DUseDiff` to get `DiffArray`). As I happened to have some older ghcs around, I tried those as well, and it seems the issue got worse around 6.8.3 (`SlowDiffArrayA-`: Array; `SlowDiffArrayDA-`: DiffArray): {{{ $ for i in *.exe ; do echo $i; time ./$i; done SlowDiffArrayA-61120081004.exe 9990001 real 0m0.307s user 0m0.015s sys 0m0.015s SlowDiffArrayA-641.exe 9990001 real 0m0.261s user 0m0.030s sys 0m0.000s SlowDiffArrayA-661.exe 9990001 real 0m0.260s user 0m0.015s sys 0m0.000s SlowDiffArrayA-683.exe 9990001 real 0m0.232s user 0m0.015s sys 0m0.000s SlowDiffArrayDA-61120081004.exe 9990001 real 0m12.932s user 0m0.031s sys 0m0.000s SlowDiffArrayDA-641.exe 9990001 real 0m7.114s user 0m0.015s sys 0m0.016s SlowDiffArrayDA-661.exe 9990001 real 0m5.774s user 0m0.015s sys 0m0.015s SlowDiffArrayDA-683.exe 9990001 real 0m12.814s user 0m0.015s sys 0m0.000s }}} (measured on Pentium M 760, 2GHz, Windows XP) [the majority of the issue probably lies in the `DiffArray` implementation, hence component `libraries`, but it seems that compiler and runtime system also play a role] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Oct 27 21:00:03 2008 From: trac at galois.com (GHC) Date: Mon Oct 27 20:55:20 2008 Subject: [GHC] #2727: DiffArray performance unusable for advertized purpose In-Reply-To: <044.19ebac4c441c1f8e8ea00498a3c1e235@localhost> References: <044.19ebac4c441c1f8e8ea00498a3c1e235@localhost> Message-ID: <053.60bf917d083e2b9b2ce344a53ef4ea09@localhost> #2727: DiffArray performance unusable for advertized purpose --------------------------------------+------------------------------------- Reporter: claus | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report and testcase! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 28 06:13:31 2008 From: trac at galois.com (GHC) Date: Tue Oct 28 06:08:48 2008 Subject: [GHC] #2652: fancier prompts for ghci In-Reply-To: <043.a8f4d98c7c46b6cf0ed186a84ca3ef31@localhost> References: <043.a8f4d98c7c46b6cf0ed186a84ca3ef31@localhost> Message-ID: <052.13d5d8af1aca784113d468ee45ed3258@localhost> #2652: fancier prompts for ghci ------------------------------+--------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by jsnx): I've integrated this with GHC 6.8.3 sources. There's not much to it. {{{ #!diff --- 0/compiler/ghci/InteractiveUI.hs 2008-06-16 10:27:16.000000000 -0700 +++ 1/compiler/ghci/InteractiveUI.hs 2008-10-28 02:57:03.000000000 -0700 @@ -1447,11 +1447,19 @@ setPrompt value = do st <- getGHCiState if null value - then io $ hPutStrLn stderr $ "syntax: :set prompt , currently \"" ++ prompt st ++ "\"" - else setGHCiState st{ prompt = remQuotes value } + then io $ hPutStrLn stderr $ + "syntax: :set prompt , currently \"" ++ prompt st ++ "\"" + else setGHCiState st{ prompt = read . handleQuotes $ value } where - remQuotes ('\"':xs) | not (null xs) && last xs == '\"' = init xs - remQuotes x = x + -- the prompt can be input with quote marks and string escaping, or + -- with plain character escaping. + handleQuotes s | length s > 2 && last s == '"' && head s == '"' = s + | otherwise = wrap . escapeQuotes $ s + wrap = ("\"" ++) . (++ "\"") + escapeQuotes ('\\':'"':r) = '\\' : '"' : escapeQuotes r + escapeQuotes ('"':r) = '\\' : '"' : escapeQuotes r + escapeQuotes (c:r) = c : escapeQuotes r + escapeQuotes [ ] = [ ] setOptions wds = do -- first, deal with the GHCi opts (+s, +t, etc.) }}} With quotes, it uses string escapes and retains spaces: {{{ Prelude> :set prompt "{- %s\n -} " {- Prelude -} }}} Without quotes, it uses only character escapes: {{{ Prelude> :set prompt {-\SP\SP%s\n\SP-}\SP {- Prelude -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 28 08:03:20 2008 From: trac at galois.com (GHC) Date: Tue Oct 28 07:58:38 2008 Subject: [GHC] #2595: Implement record update for existential and GADT data types In-Reply-To: <046.4aca36ddfd3abd8f80e6714ed9319183@localhost> References: <046.4aca36ddfd3abd8f80e6714ed9319183@localhost> Message-ID: <055.9f07251a4ac469dc92cb26e434cb5b84@localhost> #2595: Implement record update for existential and GADT data types ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tc244 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * testcase: => tc244 * status: new => closed * resolution: => fixed Comment: OK I have mostly-implemented this feature request {{{ Tue Oct 28 11:54:27 GMT Standard Time 2008 simonpj@microsoft.com * Mostly-fix Trac #2595: updates for existentials Ganesh wanted to update records that involve existentials. That seems reasonable to me, and this patch covers existentials, GADTs, and data type families. The restriction is that The types of the updated fields may mention only the universally-quantified type variables of the data constructor This doesn't allow everything in #2595 (it allows 'g' but not 'f' in the ticket), but it gets a lot closer. }}} No need to merge. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 28 08:05:05 2008 From: trac at galois.com (GHC) Date: Tue Oct 28 08:00:21 2008 Subject: [GHC] #2723: Unnecessary warning for record wildcards In-Reply-To: <044.5ab60ea4e40213824e6aecfc247bc68c@localhost> References: <044.5ab60ea4e40213824e6aecfc247bc68c@localhost> Message-ID: <053.6544649816b7dbc3e571526ead3f3a19@localhost> #2723: Unnecessary warning for record wildcards --------------------------------------+------------------------------------- Reporter: judah | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rename/should_fail/T2723 | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T2723 * owner: => igloo * type: bug => merge Comment: Fixed by {{{ Tue Oct 28 11:04:45 GMT Standard Time 2008 simonpj@microsoft.com * Fix Trac #2723: keep track of record field names in the renamer }}} Probably worth merging, if it goes over cleanly Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 28 09:06:59 2008 From: trac at galois.com (GHC) Date: Tue Oct 28 09:02:15 2008 Subject: [GHC] #2684: Stack overflow in stream-fusion library with GHC 6.10 RC In-Reply-To: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> References: <043.1a8fd23f909dfd1a99105090cda1edbc@localhost> Message-ID: <052.15f14bab0b10ddb9361f1dfa2eb42c5f@localhost> #2684: Stack overflow in stream-fusion library with GHC 6.10 RC ------------------------------+--------------------------------------------- Reporter: dons | Owner: dons Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => dons * milestone: 6.10.1 => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 28 09:21:45 2008 From: trac at galois.com (GHC) Date: Tue Oct 28 09:17:06 2008 Subject: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019 In-Reply-To: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> References: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> Message-ID: <051.405ccbc7d45a0c436ccf6110f738cdf7@localhost> #2722: < when compiling with -O option with ghc-6.10.0.20081019 -------------------------------+-------------------------------------------- Reporter: uwe | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: Optimization Loop | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by uwe): I've prepared a tar archive with all sources needed to reproduce the error. The URL is http://www.fh-wedel.de/~si/HXmlToolbox/hxt-ghc10-error.tar.gz Please untar the archive, cd into hxt-ghc10 and run "make error". This will cd into examples/arrows/hparser, compile the test prog with -O0 and execute a simple test run. Then the build is repeated but with -O and the test prog issues <>. There are a lot of sources, that shouldn't have any influence on this error. Interesting modules could be the Control.Arrow.* modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 28 21:35:53 2008 From: trac at galois.com (GHC) Date: Tue Oct 28 21:31:07 2008 Subject: [GHC] #2701: Cannot derive Data for structures containing unboxed values In-Reply-To: <053.4e805d871d5b4c042cff7a15f7231353@localhost> References: <053.4e805d871d5b4c042cff7a15f7231353@localhost> Message-ID: <062.77ab6991bbacdbdd9be3d4e1c8f33ee4@localhost> #2701: Cannot derive Data for structures containing unboxed values ----------------------------------------+----------------------------------- Reporter: batterseapower | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2701 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 28 21:36:06 2008 From: trac at galois.com (GHC) Date: Tue Oct 28 21:31:19 2008 Subject: [GHC] #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 In-Reply-To: <049.253b91b6ac2808a333ea293682ed290c@localhost> References: <049.253b91b6ac2808a333ea293682ed290c@localhost> Message-ID: <058.65f5f5bb022a1a94cdb047b140b17bab@localhost> #2713: Fixities interact badly with TH under GHC 6.10.1 20081007 ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T2713 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Oct 28 21:39:48 2008 From: trac at galois.com (GHC) Date: Tue Oct 28 21:35:02 2008 Subject: [GHC] #2700: Template Haskell pretty printer arrow always associates right In-Reply-To: <047.b71a33f0f71e965d047800e7daaf440d@localhost> References: <047.b71a33f0f71e965d047800e7daaf440d@localhost> Message-ID: <056.067d49dba962e73f841dad5ad7b2bc53@localhost> #2700: Template Haskell pretty printer arrow always associates right ---------------------------------------------+------------------------------ Reporter: aprocter | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: th pprint pretty print template | Difficulty: Unknown Testcase: th/T2700 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 29 08:52:43 2008 From: trac at galois.com (GHC) Date: Wed Oct 29 08:47:56 2008 Subject: [GHC] #2723: Unnecessary warning for record wildcards In-Reply-To: <044.5ab60ea4e40213824e6aecfc247bc68c@localhost> References: <044.5ab60ea4e40213824e6aecfc247bc68c@localhost> Message-ID: <053.c1516b4d7a34ff0e8d565a3511c483d6@localhost> #2723: Unnecessary warning for record wildcards --------------------------------------+------------------------------------- Reporter: judah | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_fail/T2723 | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Didn't go cleanly, so not merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 29 08:54:02 2008 From: trac at galois.com (GHC) Date: Wed Oct 29 08:49:43 2008 Subject: [GHC] #2714: No match in record selector Var.tcTyVarDetails In-Reply-To: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> References: <045.7eec8f01ae81c63314af48b5a797c91e@localhost> Message-ID: <054.45aea67ec2279e2867268844693ffdfa@localhost> #2714: No match in record selector Var.tcTyVarDetails --------------------------------------------------+------------------------- Reporter: morrow | Owner: merge Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: Var, tcTyVarDetails, record selector | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------------------+------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 29 09:43:15 2008 From: trac at galois.com (GHC) Date: Wed Oct 29 09:38:33 2008 Subject: [GHC] #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.111da8bcd4a73b1916f8dba9359e5e17@localhost> #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP --------------------------------------------+------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by camio): * cc: camio (added) Comment: This is also very important for those of us working on FRP at Anygma since it precludes simple console-based FRP examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 29 10:14:25 2008 From: trac at galois.com (GHC) Date: Wed Oct 29 10:09:37 2008 Subject: [GHC] #2720: eyeball/inline1 still isn't optimised with -fno-method-sharing In-Reply-To: <041.a872c76a5e9b7b0657aff218eccbf6d8@localhost> References: <041.a872c76a5e9b7b0657aff218eccbf6d8@localhost> Message-ID: <050.2dbd33b3d2f9b6ca8bd3ee6cd0dde370@localhost> #2720: eyeball/inline1 still isn't optimised with -fno-method-sharing --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I believe I've fixed this {{{ Tue Oct 28 14:08:28 GMT Standard Time 2008 simonpj@microsoft.com * Fix Trac #2720: inlining and casts The issue here is what happens when we have (f |> co) x where f is itself marked INLINE. We want callSiteInline to "see" the fact that the function is applied, and hence have some incentive to inline. I've done this by extending CoreUnfold.CallCtxt with ValAppCtxt. I think that should catch this case without messing up any of the others. }}} Do try it out. I'll close it meanwhile. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 29 11:09:57 2008 From: trac at galois.com (GHC) Date: Wed Oct 29 11:05:11 2008 Subject: [GHC] #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.b466cdbdfe3e0ad88540df83835d22b9@localhost> #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP --------------------------------------------+------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by igloo): * priority: normal => high * cc: igloo (added) Comment: I'd also find this useful -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 29 13:16:28 2008 From: trac at galois.com (GHC) Date: Wed Oct 29 13:11:40 2008 Subject: [GHC] #2728: T2627 profasm/profc: Kinds don't match in type application Message-ID: <044.db6ba324582e91584ba6d07f123338c8@localhost> #2728: T2627 profasm/profc: Kinds don't match in type application ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: T2627 Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ T2627 profasm/profc is getting a lint failure: {{{ =====> T2627(profasm) cd ./indexed-types/should_compile && '/64playpen/buildbot/x86_64-linux- stable/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output -c T2627.hs -O -prof -auto-all -fasm >T2627.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint Errors: in result of Worker Wrapper binds *** : In the expression: (\ (@ a_akP) (@ b_akQ) (@ $coDual_alQ) (@ $coDual_alR) (ds_dmA [ALWAYS Just S] :: T2627.Comm a_akP) (ds_dmB [ALWAYS Just S] :: T2627.Comm b_akQ) -> __scc {conn main:T2627} case ds_dmA of wild_B1 [ALWAYS Just A] { T2627.Rd @ a_akW @ b_akX @ $co$_alf k_ag6 [ALWAYS Just C(S)] -> case ds_dmB of wild_Xp [ALWAYS Just A] { __DEFAULT -> fail_sn8; T2627.Wr @ a_akY @ b_akZ @ $co$_al5 a_ag8 [ALWAYS Just L] r_aga [ALWAYS Just S] -> T2627.conn @ b_akX @ b_akZ @ (trans (trans (T2627.Dual b_akX) (trans (trans (T2627.Dual b_akX) (trans (trans (T2627.Dual b_akX) (trans (trans (T2627.Dual (right (trans (sym $co$_alf) (trans (trans (sym $coDual_alR) (T2627.Dual $co$_al5)) (a_akY T2627.:CoF:R1Dual b_akZ))))) (T2627.Dual (T2627.Dual b_akZ))) (trans (trans (T2627.Dual (T2627.Dual b_akZ)) (trans (right (trans (trans (sym (a_akW T2627.:CoF:R2Dual T2627.Dual b_akZ)) (trans (T2627.Dual (T2627.R (right (left (trans (sym $co$_alf) (trans (trans (sym $coDual_alR) (T2627.Dual $co$_al5)) (a_akY T2627.:CoF:R1Dual b_akZ))))) (T2627.Dual b_akZ))) (trans (T2627.Dual (trans (sym (a_akY T2627.:CoF:R1Dual b_akZ)) (trans (T2627.Dual (sym $co$_al5)) $coDual_alR))) $coDual_alQ))) $co$_al5)) b_akZ)) b_akZ))) b_akZ)) b_akZ)) b_akZ) @ (trans (trans (T2627.Dual b_akZ) (trans (trans (T2627.Dual b_akZ) (trans (trans (T2627.Dual b_akZ) (trans (T2627.Dual b_akZ) (trans (trans (T2627.Dual b_akZ) (trans (right (trans (trans (sym (a_akY T2627.:CoF:R1Dual b_akZ)) (trans (T2627.Dual (sym $co$_al5)) $coDual_alR)) $co$_alf)) b_akX)) b_akX))) b_akX)) b_akX)) b_akX) (k_ag6 (a_ag8 `cast` (trans (trans a_akY (trans (trans a_akY (trans (trans a_akY (trans (trans a_akY (trans (right (left (trans (trans (sym (a_akY T2627.:CoF:R1Dual b_akZ)) (trans (T2627.Dual (sym $co$_al5)) $coDual_alR)) $co$_alf))) a_akW)) a_akW)) a_akW)) a_akW)) a_akW :: a_akY ~ a_akW))) r_aga }; T2627.Wr @ a_all @ b_alm @ $co$_alI a_agc [ALWAYS Just L] r_age [ALWAYS Just S] -> case ds_dmB of wild_Xq [ALWAYS Just A] { __DEFAULT -> fail_sn8; T2627.Rd @ a_aln @ b_alo @ $co$_alu k_agg [ALWAYS Just C(S)] -> T2627.conn @ b_alm @ b_alo @ (trans (trans (T2627.Dual b_alm) (trans (trans (T2627.Dual b_alm) (trans (trans (T2627.Dual b_alm) (trans (trans (T2627.Dual (right (trans (sym $co$_alI) (trans (trans (sym $coDual_alR) (T2627.Dual $co$_alu)) (a_aln T2627.:CoF:R2Dual b_alo))))) (T2627.Dual (T2627.Dual b_alo))) (trans (trans (T2627.Dual (T2627.Dual b_alo)) (trans (right (trans (trans (sym (a_all T2627.:CoF:R1Dual T2627.Dual b_alo)) (trans (T2627.Dual (T2627.W (right (left (trans (sym $co$_alI) (trans (trans (sym $coDual_alR) (T2627.Dual $co$_alu)) (a_aln T2627.:CoF:R2Dual b_alo))))) (T2627.Dual b_alo))) (trans (T2627.Dual (trans (sym (a_aln T2627.:CoF:R2Dual b_alo)) (trans (T2627.Dual (sym $co$_alu)) $coDual_alR))) $coDual_alQ))) $co$_alu)) b_alo)) b_alo))) b_alo)) b_alo)) b_alo) @ (trans (trans (T2627.Dual b_alo) (trans (trans (T2627.Dual b_alo) (trans (trans (T2627.Dual b_alo) (trans (T2627.Dual b_alo) (trans (trans (T2627.Dual b_alo) (trans (right (trans (trans (sym (a_aln T2627.:CoF:R2Dual b_alo)) (trans (T2627.Dual (sym $co$_alu)) $coDual_alR)) $co$_alI)) b_alm)) b_alm))) b_alm)) b_alm)) b_alm) r_age (k_agg (a_agc `cast` (trans (trans a_all (sym (sym (trans (trans a_all (sym (sym (trans (trans a_all (sym (sym (trans (trans a_all (sym (trans (right (left (trans (trans (sym (a_aln T2627.:CoF:R2Dual b_alo)) (trans (T2627.Dual (sym $co$_alu)) $coDual_alR)) $co$_alI))) (sym a_all)))) a_aln)))) a_aln)))) a_aln)))) a_aln :: a_all ~ a_aln))) }; T2627.Fin @ $co$_akV x_ag2 [ALWAYS Just L] -> case ds_dmB of wild_Xn [ALWAYS Just A] { __DEFAULT -> fail_sn8; T2627.Fin @ $co$_akU y_ag4 [ALWAYS Just L] -> (x_ag2, y_ag4) } }) @ a_afZ @ b_ag0 @ co_wild_B1 Kinds don't match in type application: Type variable: $coDual_alQ :: T2627.Dual a_afZ ~ b_ag0 Arg type: co_wild_Xb :: T2627.Dual b_ag0 ~ a_afZ *** Offending Program *** T2627.$WRd :: forall a_afH b_afI. (a_afH -> T2627.Comm b_afI) -> T2627.Comm (T2627.R a_afH b_afI) [DataConWrapper] [Arity 1 NoCafRefs Str: DmdType L] T2627.$WRd = __inline_me (\ (@ a_afH) (@ b_afI) (tpl_B1 [ALWAYS Just L] :: a_afH -> T2627.Comm b_afI) -> T2627.Rd @ (T2627.R a_afH b_afI) @ a_afH @ b_afI @ (T2627.R a_afH b_afI) tpl_B1) T2627.$WWr :: forall a_afK b_afL. a_afK -> T2627.Comm b_afL -> T2627.Comm (T2627.W a_afK b_afL) [DataConWrapper] [Arity 2 NoCafRefs Str: DmdType LL] T2627.$WWr = __inline_me (\ (@ a_afK) (@ b_afL) (tpl_B1 [ALWAYS Just L] :: a_afK) (tpl_B2 [ALWAYS Just L] :: T2627.Comm b_afL) -> T2627.Wr @ (T2627.W a_afK b_afL) @ a_afK @ b_afL @ (T2627.W a_afK b_afL) tpl_B1 tpl_B2) T2627.$WFin :: GHC.Types.Int -> T2627.Comm T2627.Z [DataConWrapper] [Arity 1 NoCafRefs Str: DmdType L] T2627.$WFin = __inline_me (T2627.Fin @ T2627.Z @ T2627.Z) fail_sn8 :: (GHC.Types.Int, GHC.Types.Int) [Str: DmdType b] fail_sn8 = __scc {conn main:T2627 !} Control.Exception.Base.patError @ (GHC.Types.Int, GHC.Types.Int) "T2627.hs:(20,0)-(22,34)|function conn" Rec { $wconn_snA :: forall a_afZ b_ag0. (T2627.Dual a_afZ ~ b_ag0, T2627.Dual b_ag0 ~ a_afZ) => T2627.Comm a_afZ -> T2627.Comm b_ag0 -> (# GHC.Types.Int, GHC.Types.Int #) [Arity 2 Str: DmdType SS] $wconn_snA = \ (@ a_afZ) (@ b_ag0) (@ co_wild_B1) (@ co_wild_B1) (w_snv [ALWAYS Just S] :: T2627.Comm a_afZ) (w_snw [ALWAYS Just S] :: T2627.Comm b_ag0) -> case (\ (@ a_akP) (@ b_akQ) (@ $coDual_alQ) (@ $coDual_alR) (ds_dmA [ALWAYS Just S] :: T2627.Comm a_akP) (ds_dmB [ALWAYS Just S] :: T2627.Comm b_akQ) -> __scc {conn main:T2627} case ds_dmA of wild_B1 [ALWAYS Just A] { T2627.Rd @ a_akW @ b_akX @ $co$_alf k_ag6 [ALWAYS Just C(S)] -> case ds_dmB of wild_Xp [ALWAYS Just A] { __DEFAULT -> fail_sn8; T2627.Wr @ a_akY @ b_akZ @ $co$_al5 a_ag8 [ALWAYS Just L] r_aga [ALWAYS Just S] -> T2627.conn @ b_akX @ b_akZ @ (trans (trans (T2627.Dual b_akX) (trans (trans (T2627.Dual b_akX) (trans (trans (T2627.Dual b_akX) (trans (trans (T2627.Dual (right (trans (sym $co$_alf) (trans (trans (sym $coDual_alR) (T2627.Dual $co$_al5)) (a_akY T2627.:CoF:R1Dual b_akZ))))) (T2627.Dual (T2627.Dual b_akZ))) (trans (trans (T2627.Dual (T2627.Dual b_akZ)) (trans (right (trans (trans (sym (a_akW T2627.:CoF:R2Dual T2627.Dual b_akZ)) (trans (T2627.Dual (T2627.R (right (left (trans (sym $co$_alf) (trans (trans (sym $coDual_alR) (T2627.Dual $co$_al5)) (a_akY T2627.:CoF:R1Dual b_akZ))))) (T2627.Dual b_akZ))) (trans (T2627.Dual (trans (sym (a_akY T2627.:CoF:R1Dual b_akZ)) (trans (T2627.Dual (sym $co$_al5)) $coDual_alR))) $coDual_alQ))) $co$_al5)) b_akZ)) b_akZ))) b_akZ)) b_akZ)) b_akZ) @ (trans (trans (T2627.Dual b_akZ) (trans (trans (T2627.Dual b_akZ) (trans (trans (T2627.Dual b_akZ) (trans (T2627.Dual b_akZ) (trans (trans (T2627.Dual b_akZ) (trans (right (trans (trans (sym (a_akY T2627.:CoF:R1Dual b_akZ)) (trans (T2627.Dual (sym $co$_al5)) $coDual_alR)) $co$_alf)) b_akX)) b_akX))) b_akX)) b_akX)) b_akX) (k_ag6 (a_ag8 `cast` (trans (trans a_akY (trans (trans a_akY (trans (trans a_akY (trans (trans a_akY (trans (right (left (trans (trans (sym (a_akY T2627.:CoF:R1Dual b_akZ)) (trans (T2627.Dual (sym $co$_al5)) $coDual_alR)) $co$_alf))) a_akW)) a_akW)) a_akW)) a_akW)) a_akW :: a_akY ~ a_akW))) r_aga }; T2627.Wr @ a_all @ b_alm @ $co$_alI a_agc [ALWAYS Just L] r_age [ALWAYS Just S] -> case ds_dmB of wild_Xq [ALWAYS Just A] { __DEFAULT -> fail_sn8; T2627.Rd @ a_aln @ b_alo @ $co$_alu k_agg [ALWAYS Just C(S)] -> T2627.conn @ b_alm @ b_alo @ (trans (trans (T2627.Dual b_alm) (trans (trans (T2627.Dual b_alm) (trans (trans (T2627.Dual b_alm) (trans (trans (T2627.Dual (right (trans (sym $co$_alI) (trans (trans (sym $coDual_alR) (T2627.Dual $co$_alu)) (a_aln T2627.:CoF:R2Dual b_alo))))) (T2627.Dual (T2627.Dual b_alo))) (trans (trans (T2627.Dual (T2627.Dual b_alo)) (trans (right (trans (trans (sym (a_all T2627.:CoF:R1Dual T2627.Dual b_alo)) (trans (T2627.Dual (T2627.W (right (left (trans (sym $co$_alI) (trans (trans (sym $coDual_alR) (T2627.Dual $co$_alu)) (a_aln T2627.:CoF:R2Dual b_alo))))) (T2627.Dual b_alo))) (trans (T2627.Dual (trans (sym (a_aln T2627.:CoF:R2Dual b_alo)) (trans (T2627.Dual (sym $co$_alu)) $coDual_alR))) $coDual_alQ))) $co$_alu)) b_alo)) b_alo))) b_alo)) b_alo)) b_alo) @ (trans (trans (T2627.Dual b_alo) (trans (trans (T2627.Dual b_alo) (trans (trans (T2627.Dual b_alo) (trans (T2627.Dual b_alo) (trans (trans (T2627.Dual b_alo) (trans (right (trans (trans (sym (a_aln T2627.:CoF:R2Dual b_alo)) (trans (T2627.Dual (sym $co$_alu)) $coDual_alR)) $co$_alI)) b_alm)) b_alm))) b_alm)) b_alm)) b_alm) r_age (k_agg (a_agc `cast` (trans (trans a_all (sym (sym (trans (trans a_all (sym (sym (trans (trans a_all (sym (sym (trans (trans a_all (sym (trans (right (left (trans (trans (sym (a_aln T2627.:CoF:R2Dual b_alo)) (trans (T2627.Dual (sym $co$_alu)) $coDual_alR)) $co$_alI))) (sym a_all)))) a_aln)))) a_aln)))) a_aln)))) a_aln :: a_all ~ a_aln))) }; T2627.Fin @ $co$_akV x_ag2 [ALWAYS Just L] -> case ds_dmB of wild_Xn [ALWAYS Just A] { __DEFAULT -> fail_sn8; T2627.Fin @ $co$_akU y_ag4 [ALWAYS Just L] -> (x_ag2, y_ag4) } }) @ a_afZ @ b_ag0 @ co_wild_B1 @ co_wild_B1 w_snv w_snw of ww_snC { (ww_snD, ww_snE) -> (# ww_snD, ww_snE #) } T2627.conn [ALWAYS LoopBreaker Nothing] :: forall a_afZ b_ag0. (T2627.Dual a_afZ ~ b_ag0, T2627.Dual b_ag0 ~ a_afZ) => T2627.Comm a_afZ -> T2627.Comm b_ag0 -> (GHC.Types.Int, GHC.Types.Int) [Exported] [Arity 2 Worker $wconn_snA Str: DmdType SSm] T2627.conn = __inline_me (\ (@ a_afZ) (@ b_ag0) (@ co_wild_B1) (@ co_wild_B1) (w_snv [ALWAYS Just S] :: T2627.Comm a_afZ) (w_snw [ALWAYS Just S] :: T2627.Comm b_ag0) -> case $wconn_snA @ a_afZ @ b_ag0 @ co_wild_B1 @ co_wild_B1 w_snv w_snw of ww_snB { (# ww_snD, ww_snE #) -> (ww_snD, ww_snE) }) end Rec } *** End of Offense *** : Compilation had errors *** unexpected failure for T2627(profasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Oct 29 13:43:43 2008 From: trac at galois.com (GHC) Date: Wed Oct 29 13:38:55 2008 Subject: [GHC] #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) Message-ID: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) ---------------------------------+------------------------------------------ Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: major Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ This is the end of the -v output without -O2 {{{ Ready for upsweep [NONREC ModSummary { ms_hs_date = Fri Sep 5 21:53:18 CEST 2008 ms_mod = main:XMonad.StackSet, ms_imps = [Data.Map, Data.List, Data.List, Data.Maybe, Prelude] ms_srcimps = [] }] compile: input file ./XMonad/StackSet.hs Created temporary directory: /tmp/ghc14177_0 *** Checking old interface for main:XMonad.StackSet: [1 of 1] Compiling XMonad.StackSet ( XMonad/StackSet.hs, XMonad/StackSet.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 7813 *** Simplify: Result size = 6756 Result size = 6535 Result size = 6511 Result size = 6511 *** Tidy Core: Result size = 6511 *** CorePrep: }}} ...and then it stops, consuming full CPU and constant (~27MB) memory. The output with -O2 is slightly different {{{ Ready for upsweep [NONREC ModSummary { ms_hs_date = Fri Sep 5 21:53:18 CEST 2008 ms_mod = main:XMonad.StackSet, ms_imps = [Data.Map, Data.List, Data.List, Data.Maybe, Prelude] ms_srcimps = [] }] compile: input file ./XMonad/StackSet.hs Created temporary directory: /tmp/ghc14187_0 *** Checking old interface for main:XMonad.StackSet: [1 of 1] Compiling XMonad.StackSet ( XMonad/StackSet.hs, XMonad/StackSet.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 7808 *** Simplify: Result size = 6281 Result size = 6189 Result size = 6189 *** Specialise: Result size = 6189 *** Float out (not lambdas, not constants): }}} I waited for about 30 minutes before killing it. This problem doesn't seem to be present in the 6.10 branch, so the culprit must be a relatively recent patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 04:42:51 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 04:38:00 2008 Subject: [GHC] #2730: Quasiquote or TH linking may need HPC flag Message-ID: <046.eb529fb4a48a2719d84deefae728a2de@localhost> #2730: Quasiquote or TH linking may need HPC flag ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ Test `quasiquotation/qq005` fails in the `hpc` way: {{{ '/64playpen/simonpj/builds/HEAD-1/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output -c -o qq005 Main.hs -O -fhpc Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. ghc: ./Expr.o: unknown symbol `hs_hpc_module' }}} I believe the reason is this: * `Expr.hs` contains a quasiquote parser * This parser is invoked in `Main.hs` * But `Expr.hs` is compiled with `-fhpc` and contains a reference to the RTS function `hs_hpc_module` * When doing dynamic linking of `Expr.o` (to run the quasiquote parser) the linker can't find `hs_hpc_module`. (Even though `Main.hs` is also compiled with `-fhpc`. The same thing happens with Template Haskell. (Try running the `th` tests with the `hpc` way. Not all tests fail, but some do, with the same error.) I'm no expert on the dynamic linking part. Is `hs_hpc_module` (defined in `rts/Hpc.c`) always part of the RTS? Does it need to be added to a list I vaguely recall, of externally linkable symbols (perhaps `RTS_SYMBOLS` in `rts/Linker.c`) [PS: some comments explaining these lists would be v useful]? Or what? I'll milestone this for 6.10.1, because it does seem a bug that TH and HPC don't mix; but it should probably not hold up the release. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 04:43:10 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 04:38:19 2008 Subject: [GHC] #2730: Quasiquote or TH linking may need HPC flag In-Reply-To: <046.eb529fb4a48a2719d84deefae728a2de@localhost> References: <046.eb529fb4a48a2719d84deefae728a2de@localhost> Message-ID: <055.edd2a3309ae9fd2115cbba38daab3b3d@localhost> #2730: Quasiquote or TH linking may need HPC flag ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * version: 6.8.3 => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 04:48:15 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 04:43:25 2008 Subject: [GHC] #2670: Record selectors behaving badly wrt optimisation In-Reply-To: <047.05629016d0e3be252c46b232dd152edc@localhost> References: <047.05629016d0e3be252c46b232dd152edc@localhost> Message-ID: <056.741db0fe97bd1071b4c39a01ebf4351a@localhost> #2670: Record selectors behaving badly wrt optimisation ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * summary: Performance regression => Record selectors behaving badly wrt optimisation Comment: Just adding a couple more notes: * When field packing/unpacking is involved, if the selector is not inlined bodily (perhaps it is big), then we'd like strictness and CPR info; and indeed a worker/wrapper split. Again that argues for making them ordinary functions. * Injecting the selectors into the CoreBinds early (ie at the start of the optimisation passes) doesn't help much. Since they are `GlobalIds`, any uses of the selectors still don't "see" the bindings, instead using the unfolding put inside the selector by `MkId`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 05:06:30 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 05:01:40 2008 Subject: [GHC] #2731: Avoid unnecessary evaluation when unpacking constructors Message-ID: <046.faa1da08abfada8ee02e462f3ba3c08c@localhost> #2731: Avoid unnecessary evaluation when unpacking constructors -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple -----------------------------------------+---------------------------------- Consider {{{ data T a = MkT !a foo :: T (a,b) -> a foo (MkT (x,y)) = x }}} GHC will extract the first component of the `MkT`, ''evaluate it'', and then extract the first component of the pair. The evaluation step isn't needed, since the component is known to be already-evaluated. `UNPACK` directives won't work here, because the component is polymorphic. In the email thread, Tyson posted an example where this extra eval made a significant difference to his inner loop: [http://www.haskell.org/pipermail/glasgow-haskell- users/2008-October/015796.html] Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 05:17:26 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 05:12:39 2008 Subject: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019 In-Reply-To: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> References: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> Message-ID: <051.166cf802e7e99284c34cd44088eeb3a7@localhost> #2722: < when compiling with -O option with ghc-6.10.0.20081019 -------------------------------+-------------------------------------------- Reporter: uwe | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: Optimization Loop | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by simonpj): That's a big program! Can you say why you suspect `id` and `(.)`, and/or `Control.Arrow.*`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 05:51:46 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 05:46:55 2008 Subject: [GHC] #2674: ghc panic TcPat.checkArgs In-Reply-To: <047.beba89fbd265d4930e6aee37db6d8846@localhost> References: <047.beba89fbd265d4930e6aee37db6d8846@localhost> Message-ID: <056.577fbce279a0391ec8931fa0d961d820@localhost> #2674: ghc panic TcPat.checkArgs ------------------------------+--------------------------------------------- Reporter: rwbarton | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T2674 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * testcase: => th/T2674 * owner: => igloo * type: bug => merge Comment: Thanks for the report. Fixed by {{{ Thu Oct 30 09:45:28 GMT 2008 simonpj@microsoft.com * Fix Trac #2674: in TH reject empty case expressions and function definitions }}} Now from this program {{{ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH $(return [FunD (mkName "foo") []]) }}} we get the more civilised error {{{ T2674.hs:3:2: Function binding for `foo' has no equations When splicing generated code into the program }}} Pls merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 05:52:28 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 05:47:39 2008 Subject: [GHC] #2732: Incorrect requirement for building ghc Message-ID: <045.77ca0a48e50ddfcd41f5dad430a27f45@localhost> #2732: Incorrect requirement for building ghc ---------------------------------+------------------------------------------ Reporter: jputcu | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown/Multiple | Os: Unknown/Multiple ---------------------------------+------------------------------------------ At the bottom of http://www.haskell.org/ghc/download_ghc_683.html you'll see I need ghc >= 6.0 to build ghc-6.8.3. In issue #2718 I was told my ghc-6.2.2 was to old to build ghc-6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 06:08:12 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 06:03:26 2008 Subject: [GHC] #2733: Newtype deriving over phantom types broke between GHC 6.6.1 and GHC 6.8.1 Message-ID: <045.08332578d50a91aa90e88aa6250d394d@localhost> #2733: Newtype deriving over phantom types broke between GHC 6.6.1 and GHC 6.8.1 -----------------------------------------------+---------------------------- Reporter: DavidA | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: newtype deriving, phantom type | Testcase: Architecture: x86 | Os: Windows -----------------------------------------------+---------------------------- Consider the following code: {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} data Lex data Glex newtype Monomial ord = M [Int] deriving (Eq,Show) instance Ord (Monomial Lex) where compare (M xs) (M ys) = compare xs ys instance Ord (Monomial Glex) where compare (M xs) (M ys) = compare (sum xs, xs) (sum ys, ys) -- newtype Polynomial ord = P [Monomial ord] deriving (Eq,Show,Ord) newtype Polynomial ord = P [Monomial ord] deriving (Eq,Show) instance Ord (Monomial ord) => Ord (Polynomial ord) where compare (P ts) (P us) = compare ts us In 6.6.1, it was permissible to derive the Ord instance for Polynomial ord from the ord instance for Monomial ord - the commented out code would compile. In 6.8.1-3, the commented out code doesn't compile, so you have to do the derivation by hand, as shown. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 06:09:28 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 06:04:39 2008 Subject: [GHC] #2734: Newtype deriving over phantom types broke between GHC 6.6.1 and GHC 6.8.1 Message-ID: <045.a6cf847b0f75eefdc95f6ae289381471@localhost> #2734: Newtype deriving over phantom types broke between GHC 6.6.1 and GHC 6.8.1 -----------------------------------------------+---------------------------- Reporter: DavidA | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: newtype deriving, phantom type | Testcase: Architecture: x86 | Os: Windows -----------------------------------------------+---------------------------- Consider the following code: {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} data Lex data Glex newtype Monomial ord = M [Int] deriving (Eq,Show) instance Ord (Monomial Lex) where compare (M xs) (M ys) = compare xs ys instance Ord (Monomial Glex) where compare (M xs) (M ys) = compare (sum xs, xs) (sum ys, ys) -- newtype Polynomial ord = P [Monomial ord] deriving (Eq,Show,Ord) newtype Polynomial ord = P [Monomial ord] deriving (Eq,Show) instance Ord (Monomial ord) => Ord (Polynomial ord) where compare (P ts) (P us) = compare ts us In 6.6.1, it was permissible to derive the Ord instance for Polynomial ord from the ord instance for Monomial ord - the commented out code would compile. In 6.8.1-3, the commented out code doesn't compile, so you have to do the derivation by hand, as shown. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 07:45:21 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 07:40:35 2008 Subject: [GHC] #2734: Newtype deriving over phantom types broke between GHC 6.6.1 and GHC 6.8.1 In-Reply-To: <045.a6cf847b0f75eefdc95f6ae289381471@localhost> References: <045.a6cf847b0f75eefdc95f6ae289381471@localhost> Message-ID: <054.3a4ee1a491fa561074a22b546d5d19d9@localhost> #2734: Newtype deriving over phantom types broke between GHC 6.6.1 and GHC 6.8.1 --------------------------------------------+------------------------------- Reporter: DavidA | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: newtype deriving, phantom type | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Old description: > Consider the following code: > > {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} > > data Lex > > data Glex > > newtype Monomial ord = M [Int] deriving (Eq,Show) > > instance Ord (Monomial Lex) where > compare (M xs) (M ys) = compare xs ys > > instance Ord (Monomial Glex) where > compare (M xs) (M ys) = compare (sum xs, xs) (sum ys, ys) > > -- newtype Polynomial ord = P [Monomial ord] deriving (Eq,Show,Ord) > > newtype Polynomial ord = P [Monomial ord] deriving (Eq,Show) > > instance Ord (Monomial ord) => Ord (Polynomial ord) where > compare (P ts) (P us) = compare ts us > > In 6.6.1, it was permissible to derive the Ord instance for Polynomial > ord from the ord instance for Monomial ord - the commented out code would > compile. In 6.8.1-3, the commented out code doesn't compile, so you have > to do the derivation by hand, as shown. New description: Consider the following code: {{{ {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} data Lex data Glex newtype Monomial ord = M [Int] deriving (Eq,Show) instance Ord (Monomial Lex) where compare (M xs) (M ys) = compare xs ys instance Ord (Monomial Glex) where compare (M xs) (M ys) = compare (sum xs, xs) (sum ys, ys) -- newtype Polynomial ord = P [Monomial ord] deriving (Eq,Show,Ord) newtype Polynomial ord = P [Monomial ord] deriving (Eq,Show) instance Ord (Monomial ord) => Ord (Polynomial ord) where compare (P ts) (P us) = compare ts us }}} In 6.6.1, it was permissible to derive the Ord instance for Polynomial ord from the ord instance for Monomial ord - the commented out code would compile. In 6.8.1-3, the commented out code doesn't compile, so you have to do the derivation by hand, as shown. Comment: I'm afraid this is by design: the 6.6 deriving mechanism could all-too- easily infer a stupid context for the derived instance declaration. However 6.10 lets you ''specify'' the context for the derived instance declaration (rather than having it inferred) thus: {{{ newtype Polynomial ord = P [Monomial ord] deriving (Eq,Show) deriving instance Ord (Monomial ord) => Ord (Polynomial ord) }}} The `deriving instance` is half way between `deriving(Ord)` and giving a full instance declaration, which you didn't want to do. It's documented under "standalone deriving" in the user manual. If the documentation could be improved, I'd welcome concrete suggestions. Meanwhile I'm closing the bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 07:45:44 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 07:40:54 2008 Subject: [GHC] #2733: Newtype deriving over phantom types broke between GHC 6.6.1 and GHC 6.8.1 In-Reply-To: <045.08332578d50a91aa90e88aa6250d394d@localhost> References: <045.08332578d50a91aa90e88aa6250d394d@localhost> Message-ID: <054.66aacebbf44eb6264a220f3d99c26ebb@localhost> #2733: Newtype deriving over phantom types broke between GHC 6.6.1 and GHC 6.8.1 --------------------------------------------+------------------------------- Reporter: DavidA | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: newtype deriving, phantom type | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Dup #2734. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 08:35:59 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 08:31:08 2008 Subject: [GHC] #2695: bogus "syntactically distinct contexts" error In-Reply-To: <044.f308f1282aefb65817439a6f79a47353@localhost> References: <044.f308f1282aefb65817439a6f79a47353@localhost> Message-ID: <053.b2932b4a5bfc6ca59b584845ccbec223@localhost> #2695: bogus "syntactically distinct contexts" error -------------------------------------+-------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by simonpj): * priority: normal => low * milestone: 6.10.2 => _|_ Comment: Good point. The requirement that the contexts of all the declarations in a mutually recursive group must be identical, even though really we have polymorphic recursion, is a very tiresome Haskell 98 thing. What is biting us here is that we're trying to unify the two contexts, but since `Basis` is a type function, knowing that `(Basis a1)` = `(Basis a2)` does not allow us to conclude that `a1` = `a2`. We could solve this by writing a syntactic-identity checker (oh, but it has to be subject to alpha-renaming...), but it just doesn't seem worth the bother. The solution is to use `-XRelaxedPolyRec`, which lifts the restriction altogether. Haskell Prime will probably have this as the default. Meanwhile I'll leave this open at low priority. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 09:12:30 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 09:07:42 2008 Subject: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019 In-Reply-To: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> References: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> Message-ID: <051.fa540e41cf413800824680a056b0416d@localhost> #2722: < when compiling with -O option with ghc-6.10.0.20081019 -------------------------------+-------------------------------------------- Reporter: uwe | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: Optimization Loop | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by igloo): I've attached a single module case: {{{ $ ghc -fforce-recomp --make HXmlParser.hs -Wall && ./HXmlParser [1 of 1] Compiling Main ( HXmlParser.hs, HXmlParser.o ) Linking HXmlParser ... Foo 1 Foo 2 HXmlParser: XXX }}} {{{ $ ghc -fforce-recomp --make HXmlParser.hs -O -Wall && ./HXmlParser [1 of 1] Compiling Main ( HXmlParser.hs, HXmlParser.o ) Linking HXmlParser ... Foo 1 HXmlParser: <> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 11:11:49 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 11:07:00 2008 Subject: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019 In-Reply-To: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> References: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> Message-ID: <051.65354c4e2ce57450eac2b502ec692594@localhost> #2722: < when compiling with -O option with ghc-6.10.0.20081019 -------------------------------+-------------------------------------------- Reporter: uwe | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: Optimization Loop | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by simonpj): OK I know what is happening. Sigh. I boiled it down still more: {{{ module Foo (main, arid1, arid2) where import Prelude hiding (id, (.)) import qualified Prelude import Control.Category import Control.Arrow import System.IO import Debug.Trace main = runXIOState arid1 -- Loop with arid1 -- Works with arid2 arid1 :: Arrow m => m a a arid1 = arr id arid2 :: Arrow m => m a a arid2 = arr Prelude.id runXIOState :: IOSLA () c -> IO [c] runXIOState f = runIOSLA f () newtype IOSLA a b = IOSLA { runIOSLA :: a -> IO [b] } instance Arrow IOSLA where arr f = IOSLA $ \ x -> return [f x] instance Category IOSLA where id = arr id -- arr :: Arrow m => (b->c) -> m b c -- id :: Category m => m b b -- (arr id) :: Arrow m => m a a }}} What is happening is this. * In `Control.Arrow` we find the following rewrite rule {{{ {-# RULES "identity" arr id = id }}} * But, as you see above, `id` is defined to be `arr id`. So the result is (unsurprisingly) a loop. I'm not sure whether the fault lies with the person who wrote the RULE in `Control.Arrow`, or the person who wrote the instance of IOSLA above. (The instance does look suspicious, because `Category` is a superclass of `Arrow`, and yet uses the arrow `arr` method to define `id`.) Very tricky to track down. At all events I say that GHC is not at fault. I'm leaving this open because someone should * Decide whether the rules in `Control.Arrow` are valid in general. * If so, write some documentation somewhere about the constraints that these rules impose on instance declarations. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 13:01:12 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 12:56:20 2008 Subject: [GHC] #2728: T2627 profasm/profc: Kinds don't match in type application In-Reply-To: <044.db6ba324582e91584ba6d07f123338c8@localhost> References: <044.db6ba324582e91584ba6d07f123338c8@localhost> Message-ID: <053.2c30d16895adf578e2937148ec6eb9e5@localhost> #2728: T2627 profasm/profc: Kinds don't match in type application ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2627 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Tue Oct 21 15:31:56 BST 2008 simonpj@microsoft.com * Do proper cloning in worker/wrapper splitting See Note [Freshen type variables] in WwLib. We need to clone type variables when building a worker/wrapper split, else we simply get bogus code, admittedly in rather obscure situations. I can't quite remember what program showed this up, unfortunately, but there definitely *was* one! (You get a Lint error.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 13:02:33 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 12:57:42 2008 Subject: [GHC] #2674: ghc panic TcPat.checkArgs In-Reply-To: <047.beba89fbd265d4930e6aee37db6d8846@localhost> References: <047.beba89fbd265d4930e6aee37db6d8846@localhost> Message-ID: <056.ec43628d400560c9400a1b3819cf49de@localhost> #2674: ghc panic TcPat.checkArgs ------------------------------+--------------------------------------------- Reporter: rwbarton | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T2674 | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Oct 30 20:16:16 2008 From: trac at galois.com (GHC) Date: Thu Oct 30 20:11:29 2008 Subject: [GHC] #1291: Binary Solaris build fails on Solaris 9 In-Reply-To: <044.da39aece29339a0f32ded51c36797f3d@localhost> References: <044.da39aece29339a0f32ded51c36797f3d@localhost> Message-ID: <053.93edbd917a534fd39196d3500f9274c8@localhost> #1291: Binary Solaris build fails on Solaris 9 --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Build System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by guest): I'm working on getting this working on solaris 8. I will post some notes once/if I get it working. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 06:06:13 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 06:01:23 2008 Subject: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019 In-Reply-To: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> References: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> Message-ID: <051.6f7b8b4276225c9c74510b0b57c2f722@localhost> #2722: < when compiling with -O option with ghc-6.10.0.20081019 -------------------------------+-------------------------------------------- Reporter: uwe | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: arrows | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by uwe): The guy who wrote the instance of IOSLA that was me. I took the advice from Don Stewarts wiki page for porting arrow code to ghc-6.10. As far as I see, in the definition of {{{ id = arr id }}} the id on the right hand side is another one than id on the left. The optimisation RULE above only holds for the instance Category (->), not for others. So the application of this rule should be restricted to (->). By the way, would it be a workaround for me to define the id explicitly, not using the pure function id? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 06:12:25 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 06:07:34 2008 Subject: [GHC] #2722: < when compiling with -O option with ghc-6.10.0.20081019 In-Reply-To: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> References: <042.92b72b67c0e471e2bc1e2ec20b93b90f@localhost> Message-ID: <051.303c51e47aadb4773df3555f91f750d2@localhost> #2722: < when compiling with -O option with ghc-6.10.0.20081019 -------------------------------+-------------------------------------------- Reporter: uwe | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: arrows | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by simonpj): Well the `Arrow` class in `Control.Arrow` is immediately followed by a whole bunch of rules: {{{ {-# RULES "identity" arr id = id "compose/arr" forall f g . (arr f) . (arr g) = arr (f . g) "first/arr" forall f . first (arr f) = arr (first f) "second/arr" forall f . second (arr f) = arr (second f) "product/arr" forall f g . arr f *** arr g = arr (f *** g) "fanout/arr" forall f g . arr f &&& arr g = arr (f &&& g) "compose/first" forall f g . (first f) . (first g) = first (f . g) "compose/second" forall f g . (second f) . (second g) = second (f . g) #-} }}} If you are saying that they are not valid in general (eg you say the first is valid only for `(->)`), then these rules had better be speicialised for the types they work for. Can you and Ross discuss this, and figure out what to do? It's not a GHC issue any more: rather a question of the Arrow/Category library design. Simon PS: Yes if you define `id` explicitly that ought to be ok. But remember that the RULE `arr id ---> id` is still going to apply (perhaps bogusly?) at all arrows. So you want to do more than work around the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 06:23:01 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 06:18:07 2008 Subject: [GHC] #2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields In-Reply-To: <047.a4131859623f35304148b8ddaa8f3bbb@localhost> References: <047.a4131859623f35304148b8ddaa8f3bbb@localhost> Message-ID: <056.a8c48e6622d4051fda4cb3ed144607c2@localhost> #2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields ------------------------------+--------------------------------------------- Reporter: aslatter | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * priority: normal => low * milestone: 6.10 branch => _|_ Comment: Here's what is happening. The compare functions for A and B look like this (initially): {{{ compareA :: A -> A -> Ordering compareA (A x1 .. x8) (A y1 .. y8) = compare (B x1 .. x8) (B y1 .. y8) compareB :: B -> B -> Ordering compareB (B x1 .. x8) (B y1 .. y8) = if x1>y1 then GT else ... blah blah blah... }}} Note that the signature of `compareB` '''must''' be `B -> B -> Ordering`, so `compareA` is obliged to re-box the B argument. That always potentially happens when you use `{-# UNPACK #-}`: if you match on the constructor you may need to construct a value of the unpacked type to pass on to some other function. OK after strictness analysis you might hope that `compareB` gets 16 arguments. But GHC is wary about giving workers an arbitrarily large number of arguments, so it has an arbitrary threshold of 10. As a result, the worker for `compareB` looks like this: {{{ $wcompareB :: Int# -> ... -> Int# -> B -> Ordering $wcompareB x1 .. x8 (B y1 .. y8) = }}} The first argument is unpacked but not the second. And that is what is happening to you. I don't know a good solution in general. `{-# UNPACK #-}` can (and must) lead to the possibility of reboxing. (In this case `compareB` is strict, so its wrapper may do unboxing ,up to the threshold, but in general the called function may be lazy.) There is a workaround here: the flag `-fmax-worker-args=N` will change the threshold to N, and that fixes the problem. But it's not a ''satisfying'' fix. I'll leave this open at low priority. By all means contribute suggestions! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 10:27:35 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 10:22:42 2008 Subject: [GHC] #2652: fancier prompts for ghci In-Reply-To: <043.a8f4d98c7c46b6cf0ed186a84ca3ef31@localhost> References: <043.a8f4d98c7c46b6cf0ed186a84ca3ef31@localhost> Message-ID: <052.b19311300d90b42e15642bb4fa9a9dc1@localhost> #2652: fancier prompts for ghci ------------------------------+--------------------------------------------- Reporter: jsnx | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 10:31:31 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 10:26:38 2008 Subject: [GHC] #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine In-Reply-To: <045.73e9a3354e42db349317d7c1c2959ccf@localhost> References: <045.73e9a3354e42db349317d7c1c2959ccf@localhost> Message-ID: <054.36232a5dd7af778916571af7f680455f@localhost> #2718: Building ghc-6.8.3 with ghc-6.2.2 failed on Red Hat 7.3 machine --------------------------+------------------------------------------------- Reporter: jputcu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: blocker | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Comment (by igloo): Replying to [comment:3 jputcu]: > Two notes on that: > > 1) At the bottom of http://www.haskell.org/ghc/download_ghc_683.html, version 6.0 is mentioned as a requirement, this should then be corrected. > > 2) Can't the configure script be used to check correct versions of ghc. #2732 opened for these. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 10:32:44 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 10:27:51 2008 Subject: [GHC] #2732: Incorrect requirement for building ghc In-Reply-To: <045.77ca0a48e50ddfcd41f5dad430a27f45@localhost> References: <045.77ca0a48e50ddfcd41f5dad430a27f45@localhost> Message-ID: <054.fd886f23203b562b7e99c620c4486e43@localhost> #2732: Incorrect requirement for building ghc ------------------------------+--------------------------------------------- Reporter: jputcu | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 10:57:41 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 10:52:48 2008 Subject: [GHC] #2652: fancier prompts for ghci In-Reply-To: <043.a8f4d98c7c46b6cf0ed186a84ca3ef31@localhost> References: <043.a8f4d98c7c46b6cf0ed186a84ca3ef31@localhost> Message-ID: <052.b0b641d0dc03b9c8b6eee50aef0838d5@localhost> #2652: fancier prompts for ghci ------------------------------+--------------------------------------------- Reporter: jsnx | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the patch! I've applied a slightly different version: Prompt strings starting with " are treated as Haskell strings; otherwise they are treated as literal strings. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 13:17:13 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 13:12:20 2008 Subject: [GHC] #2732: Incorrect requirement for building ghc In-Reply-To: <045.77ca0a48e50ddfcd41f5dad430a27f45@localhost> References: <045.77ca0a48e50ddfcd41f5dad430a27f45@localhost> Message-ID: <054.949756aeaaf086c2c586b4371991cb88@localhost> #2732: Incorrect requirement for building ghc ------------------------------+--------------------------------------------- Reporter: jputcu | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. I've fixed the webpage, and the configure scripts in HEAD and 6.10 already check that they have a new enough version of GHC to build with. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 13:36:57 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 13:32:04 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.04736e687c11234ae8d06385f49097d9@localhost> #2337: Data.Array documentation utterly broken ------------------------------+--------------------------------------------- Reporter: japple | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Oct 31 17:12:12 2008 From: trac at galois.com (GHC) Date: Fri Oct 31 17:07:22 2008 Subject: [GHC] #1837: ghc-pkg should not accept unversioned depends In-Reply-To: <045.5a240ed44745ae5d43f18d5941f21a30@localhost> References: <045.5a240ed44745ae5d43f18d5941f21a30@localhost> Message-ID: <054.c222722cd4f13105623cdba403e03361@localhost> #1837: ghc-pkg should not accept unversioned depends ------------------------------+--------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.2 Component: Build System | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: Looks like when the warning was removed, the test was too. I've reinstated it. -- Ticket URL: GHC The Glasgow Haskell Compiler