From trac at galois.com Fri Jun 1 03:59:44 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1361: When trying to run yi, it fails to compile main, and exits with an error In-Reply-To: <071.07119ca2c85e23fc13ef6f27e330a91f@localhost> References: <071.07119ca2c85e23fc13ef6f27e330a91f@localhost> Message-ID: <080.550f0de2305957fbd44feeb2f3965565@localhost> #1361: When trying to run yi, it fails to compile main, and exits with an error -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by guest): I have a similar setup and a similar problem. It manifests itself slightly differently. I have a gentoo system with my own ebuilds for ghc-6.6.1 (simply renaming the 6.6 ebuild from the haskell overlay) and cabal-1.1.6.2 (likewise). When I try to install yi (using the 0.2 ebuild from the overlay) everything goes (apparently) fine until the linking stage when the following output ensues: {{{ 1 of 4] Compiling Yi.Kernel ( Yi/Kernel.hs, dist/build/yi/yi- tmp/Yi/Kernel.o ) [2 of 4] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/yi/yi- tmp/Yi/Debug.o ) [3 of 4] Compiling Yi.Boot ( Yi/Boot.hs, dist/build/yi/yi- tmp/Yi/Boot.o ) [4 of 4] Compiling Main ( Main.hs, dist/build/yi/yi-tmp/Main.o ) Linking dist/build/yi/yi ... /usr/lib/ghc-6.6.1/libHSghc.a(HeaderInfo.o): In function `r6kr_info': : undefined reference to `Cabalzm1zi1zi6zi2_LanguageziHaskellziExtension_optional_info' /usr/lib/ghc-6.6.1/libHSghc.a(HeaderInfo.o): In function `s6sB_info': : undefined reference to `Cabalzm1zi1zi6zi2_LanguageziHaskellziExtension_zdwshowsPrec_info' /usr/lib/ghc-6.6.1/libHSghc.a(HeaderInfo.o): In function `s6ub_info': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziCompiler_lvl31_info' /usr/lib/ghc-6.6.1/libHSghc.a(HeaderInfo.o): In function `s6uf_info': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziCompiler_zddEq_closure' /usr/lib/ghc-6.6.1/libHSghc.a(HeaderInfo.o): In function `s6Ka_0_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziCompiler_polyzugo_info' /usr/lib/ghc-6.6.1/libHSghc.a(HeaderInfo.o): In function `s6Kd_0_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziCompiler_polyzugo1_info' /usr/lib/ghc-6.6.1/libHSghc.a(HeaderInfo.o):(.rodata+0x0): undefined reference to `Cabalzm1zi1zi6zi2_LanguageziHaskellziExtension_optional_closure' /usr/lib/ghc-6.6.1/libHSghc.a(HeaderInfo.o):(.rodata+0x1cc): undefined reference to `Cabalzm1zi1zi6zi2_LanguageziHaskellziExtension_zdwshowsPrec_closure' /usr/lib/ghc-6.6.1/libHSghc.a(HeaderInfo.o):(.rodata+0x1dc): undefined reference to `Cabalzm1zi1zi6zi2_DistributionziCompiler_lvl31_closure' /usr/lib/ghc-6.6.1/libHSghc.a(PackageConfig.o): In function `s23p_1_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_a_closure' /usr/lib/ghc-6.6.1/libHSghc.a(Packages.o): In function `s79o_1_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_a_closure' /usr/lib/ghc-6.6.1/libHSghc.a(Packages.o): In function `s7be_1_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_a_closure' /usr/lib/ghc-6.6.1/libHSghc.a(Packages.o): In function `s7jH_1_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_a_closure' /usr/lib/ghc-6.6.1/libHSghc.a(Packages.o): In function `s7xm_1_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_a_closure' /usr/lib/ghc-6.6.1/libHSghc.a(Packages.o): In function `s7zp_info': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_zeze_info' /usr/lib/ghc-6.6.1/libHSghc.a(Packages.o): In function `s7HJ_1_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_a_closure' /usr/lib/ghc-6.6.1/libHSghc.a(Linker.o): In function `s93a_1_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_a_closure' /usr/lib/ghc-6.6.1/libHSghc.a(Linker.o): In function `s94C_1_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_a_closure' /usr/lib/ghc-6.6.1/libHSghc.a(Finder.o): In function `s7lE_1_alt': : undefined reference to `Cabalzm1zi1zi6zi2_DistributionziPackage_a_closure' collect2: ld returned 1 exit status }}} Getting the darcs version and making with "make emacs" ends the same way. Is this the same issue? -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 04:21:10 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1400: :set +r doesn't work for interpreted modules In-Reply-To: <071.9f78afaebdfa5d8fda39b96af6dcc44f@localhost> References: <071.9f78afaebdfa5d8fda39b96af6dcc44f@localhost> Message-ID: <080.6f87937b961fca9bcfff78cdad62a765@localhost> #1400: :set +r doesn't work for interpreted modules ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by simonmar): * difficulty: Unknown => Moderate (1 day) * component: Compiler => GHCi * milestone: => 6.10 * priority: high => normal * summary: Incoherent cache behaviour ghci in combination with Debug.trace => :set +r doesn't work for interpreted modules Comment: `:set +r` is supposed to do what you want, but it has never worked for interpreted code, only compiled code (and of course, the debugger only works for interpreted code, so that doesn't really help). I've changed the subject of the bug to reflect this. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 10:30:38 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #393: functions without implementations In-Reply-To: <071.6387029680088621b265d68d630d3a7d@localhost> References: <071.6387029680088621b265d68d630d3a7d@localhost> Message-ID: <080.c0840dc1704a1a1665cd019076c65322@localhost> #393: functions without implementations ----------------------------------------+----------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) | Version: None Severity: normal | Resolution: None Keywords: | Difficulty: Easy (1 hr) Os: Multiple | Testcase: Architecture: Multiple | ----------------------------------------+----------------------------------- Changes (by maeder@tzi.de): * architecture: Unknown => Multiple * difficulty: Unknown => Easy (1 hr) * component: None => Compiler (Type checker) * priority: lowest => normal * severity: minor => normal * status: assigned => new * owner: nobody => simonpj * os: Unknown => Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 10:37:05 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: =?utf-8?q?=5BGHC=5D_=231401=3A_otherwise_ambiguous_field_names_s?= =?utf-8?q?houldn=E2=80=99t_be_treated_as_ambiguous_when_the_data_construc?= =?utf-8?q?tor_is_known?= Message-ID: <071.4e28ebfc435b1b3bdd79867549052c18@localhost> #1401: otherwise ambiguous field names shouldn?t be treated as ambiguous when the data constructor is known -----------------------------------------+---------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------------------------+---------------------------------- Consider these three module definitions: {{{ module A where data A = A { label :: Char } }}} {{{ module B where data B = B { label :: Char } }}} {{{ module X where import A import B a = A { label = 'a' } b = B { label = 'b' } f (A { label = a }) (B { label = b }) = (a,b) }}} GHC currently treats all the occurences of {{{label}}} in module {{{C}}} as ambiguous thereby conforming to the Haskell?98 standard. However, in all these cases there is only one field to which {{{label}}} can refer since the data constructor is known. So it should be possible to let GHC treat the above code as legal by using a certain compiler option. This would make the use of Haskell?98 records much more comfortable in certain cases. Fields in different data types could be named equally if they denote similar concepts without forcing the user of the data types to qualify the field names over and over again. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From g9ks157k at acme.softbase.org Fri Jun 1 10:43:47 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Jul 19 09:48:43 2007 Subject: [Haskell] ambiguous record field names which =?utf-8?q?actual?= =?utf-8?b?bHkJYXJlbuKAmXQ=?= ambigious In-Reply-To: References: <200705281741.18938.g9ks157k@acme.softbase.org> <200705291822.24801.g9ks157k@acme.softbase.org> Message-ID: <200706011643.47808.g9ks157k@acme.softbase.org> Am Dienstag, 29. Mai 2007 18:46 schrieb Simon Peyton-Jones: > | But wouldn?t it be worthwhile to allow this kind of stuff as a language > | extension? It would make life easier in a couple of situations. I don?t > | like the idea of using advanced record implemenations based on contended > | language extensions (undecidable instances, etc.), thereby probably > | loosing pattern matching, just to get rid of the need to qualify field > | names. :-( > > By all means! Make a feature request for GHC, as precisely stated as > possible. Done. :-) > (Better still, implement it.) I might try if I find the time. However, it would be the first time that I hack on GHC. So could anyone give me some hints about at which places of the code I would have approximately to do what in order to implement this feature? > Remember that you don't always get rid of the need to qualify field names, > just in cases (a) and (b). Of course. > S Best wishes, Wolfgang _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 12:35:06 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1402: panic in GHC when building QuickCheck with optimization Message-ID: <071.20f91518043ad5301ba7bfdcd1282607@localhost> #1402: panic in GHC when building QuickCheck with optimization -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 -----------------------+---------------------------------------------------- When building QuickCheck, I get: {{{ cdsmith@devtools:~/tmp/QuickCheck$ runhaskell Setup build Preprocessing library QuickCheck-2.0... Building QuickCheck-2.0... Glasgow Haskell Compiler, Version 6.7.20070529, for Haskell 98, compiled by GHC version 6.7.20070529 Using package config file: /usr/local/lib/ghc-6.7.20070529/package.conf wired-in package base mapped to base-2.1 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-0.1 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Test.QuickCheck,Test.QuickCheck.Arbitrary,Test.QuickCheck. Function,Test.QuickCheck.Gen,Test.QuickCheck.Monadic,Test.QuickCheck.Property,Te st.QuickCheck.Test,Test.QuickCheck.Exception,Test.QuickCheck.Text Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Fri Jun 1 10:28:15 MDT 2007 ms_mod = QuickCheck-2.0:Test.QuickCheck.Gen, ms_imps = [Control.Monad.Reader, Control.Monad, System.Random] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Fri Jun 1 10:11:40 MDT 2007 ms_mod = QuickCheck-2.0:Test.QuickCheck.Arbitrary, ms_imps = [Control.Monad, Data.List, System.Random, Data.Ratio, Data.Char, Test.QuickCheck.Gen] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Fri Jun 1 10:11:39 MDT 2007 ms_mod = QuickCheck-2.0:Test.QuickCheck.Exception, ms_imps = [Control.Exception] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Fri Jun 1 10:11:39 MDT 2007 ms_mod = QuickCheck-2.0:Test.QuickCheck.Text, ms_imps = [Data.IORef, System.IO] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Fri Jun 1 10:11:40 MDT 2007 ms_mod = QuickCheck-2.0:Test.QuickCheck.Property, ms_imps = [System.IO, Data.IORef, Control.Concurrent, Test.QuickCheck.Exception, Test.QuickCheck.Text, Test.QuickCheck.Arbitrary, Test.QuickCheck.Gen] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Fri Jun 1 10:11:40 MDT 2007 ms_mod = QuickCheck-2.0:Test.QuickCheck.Test, ms_imps = [Data.List, Data.Char, System.Random, Test.QuickCheck.Exception, Test.QuickCheck.Text, Test.QuickCheck.Property, Test.QuickCheck.Gen] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Fri Jun 1 10:11:40 MDT 2007 ms_mod = QuickCheck-2.0:Test.QuickCheck.Monadic, ms_imps = [System.IO.Unsafe, Control.Monad.ST, Control.Monad, Test.QuickCheck.Arbitrary, Test.QuickCheck.Property, Test.QuickCheck.Gen] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Fri Jun 1 10:11:40 MDT 2007 ms_mod = QuickCheck-2.0:Test.QuickCheck.Function, ms_imps = [System.IO.Unsafe, Data.List, Data.IORef, Test.QuickCheck.Property, Test.QuickCheck.Arbitrary, Test.QuickCheck.Gen] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Fri Jun 1 10:11:40 MDT 2007 ms_mod = QuickCheck-2.0:Test.QuickCheck, ms_imps = [Test.QuickCheck.Test, Test.QuickCheck.Property, Test.QuickCheck.Arbitrary, Test.QuickCheck.Gen] ms_srcimps = [] }] compile: input file Test/QuickCheck/Gen.hs Created temporary directory: /tmp/ghc2049_0 *** Checking old interface for QuickCheck-2.0:Test.QuickCheck.Gen: [1 of 9] Compiling Test.QuickCheck.Gen ( Test/QuickCheck/Gen.hs, dist/build/Test /QuickCheck/Gen.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 1180 *** Simplify: Result size = 803 Result size = 789 Result size = 789 *** Specialise: *** Deleting temp files: Deleting: /tmp/ghc2049_0/ghc2049_0.s Warning: deleting non-existent /tmp/ghc2049_0/ghc2049_0.s *** Deleting temp dirs: Deleting: /tmp/ghc2049_0 ghc-6.7.20070529: panic! (the 'impossible' happened) (GHC version 6.7.20070529 for i386-unknown-linux): my_zipEqual [] [random-1.0:System.Random.$f6{v r2X} [gid]] QuickCheck-2.0:Test.QuickCheck.Gen.choose{v r6H} [lid] [Just base:GHC.Base.I nt{(w) tc 3J}] \ (@ a{tv asq} [sk] :: base:GHC.Prim.*{(w) tc 34d}) -> (a_sIo{v} [lid] @ a{tv asq} [sk]) `cast` (random-1.0:System.Random.Random{tc r33} a{tv asq} [sk] -> (a{tv asq} [sk], a{tv asq} [sk]) -> base:GHC.Prim.sym{(w) tc 34v} ((QuickCheck-2.0:Test.QuickCheck.Gen.:CoGen{tc rfI}) a{tv asq} [sk]) :: (random-1.0:System.Random.Random{tc r33} a{tv asq} [sk]) => (a{tv asq} [sk], a{tv asq} [sk]) -> random-1.0:System.Random.StdGen{tc r35} -> base:GHC.Base.Int{(w) tc 3J} -> a{tv asq} [sk] ~ (random-1.0:System.Random.Random{tc r33} a{tv asq} [sk]) => (a{tv asq} [sk], a{tv asq} [sk]) -> QuickCheck-2.0:Test.QuickCheck.Gen.Gen{tc r76} a{tv asq} [sk]) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If I build with -Onot, the error does not occur. {{{ cdsmith@devtools:~/tmp/QuickCheck$ uname -a Linux devtools 2.4.27-2-k7 #1 Tue Aug 16 17:30:14 JST 2005 i686 GNU/Linux }}} The error occurs in: {{{ -- | Generates a random element in the given inclusive range. choose :: Random a => (a,a) -> Gen a choose rng = MkGen (\r _ -> let (x,_) = randomR rng r in x) }}} The GHC version is one that I pulled from darcs head on the 29th of May. It does have one local modification, but in an unrelated part of the compiler (the GHCi banner patch I sent to the cvs-ghc list on 6/1/2007) -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 14:32:19 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1403: System.Posix.Types.UserID and others missing from Windows distribution Message-ID: <071.95b7aa0fd76b0fc64e2874f94c318211@localhost> #1403: System.Posix.Types.UserID and others missing from Windows distribution ---------------------------------+------------------------------------------ Reporter: jgbailey@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 ---------------------------------+------------------------------------------ I have installed the binary package of GHC 6.6.1 prepared by Sigbjorn Finne. It's System.Posix.Types module does not export the UserID or GroupID data types. This breaks the unix-compat package (version 0.1), which depends on those types. Is this an intentional omission or is it a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 15:55:40 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1404: allow more type signatures Message-ID: <071.59d223f273558ac858eb9a3327d41678@localhost> #1404: allow more type signatures ------------------------------+--------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- (idea triggered by #393) Allow multiple copies of a type-signature in a module, such that it is an error if they're not equivalent, but they don't have to be syntactically equal ( {{{f :: ShowS}}} {{{f :: String -> String}}} is okay). It would also be nice to allow any name in scope at top-level (even if imported) to be given a type signature. But that raises a question: can these type signatures give a more specific type than that of the raw imported function, the way normal function type signatures can with regards to their implementation? Use cases: (1. making sure multiple implementations give the same interface, generally varying by #ifdef) (2. asserting that something's type can be specified in two different weird ways). I don't really want to abandon having a type-signature right above every function definition even if it is a duplicate. (1.) would be fixed by allowing type signatures in export lists instead. I suppose these could be more restrictive than in the module and not affect the module, e.g. {{{ module X (idN :: Int -> Int, true) where idN n = n true :: Bool true = idN True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 17:04:04 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC Message-ID: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> #1405: Make ghc (stage1) be compilable by non-GHC ---------------------------+------------------------------------------------ Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ---------------------------+------------------------------------------------ This depends a bit on the existence of a good-enough non-GHC compiler. Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet. Also pattern guards might need to be implemented in that compiler. Maybe for testing, a ghc that doesn't define __GLASGOW_HASKELL__ (and doesn't use ghc-specific flags ??) could be used too. See http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962 ... GHC also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that everyone provides, but would still be good to document. I'm working on this now, we'll see how far I get --Isaac -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 19:57:38 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1197: Windows: conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed: Not enough storage is available to process this command. In-Reply-To: <071.d0f4238e279c5a8a97d8ee42386d0a36@localhost> References: <071.d0f4238e279c5a8a97d8ee42386d0a36@localhost> Message-ID: <080.32395fa3a8e060023f50a9945aef9894@localhost> #1197: Windows: conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed: Not enough storage is available to process this command. -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: conc023 Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by mwassell@bigpond.net.au): From Mark (mwassell@bigpond.net.au) I am getting similar when running my program inside GHCi (6.6.1). When the program is compiled to a exe then it doesn't occur. Also under 6.6.0 it runs fine in GHCi. The program is HJS and occurs when parsing (parse built on parsec) a very simple statement *and* when the parse function is wrapped in a case statement. If I call the parse function directly there is no problem. So case parseProgram fn s of Right r -> Just r _ -> cases the problem whilst parseProgram fn s does not. During the run memory usage will exceed 1GB. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 20:02:53 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #364: panic! ... forkM Declaration for tables{v} In-Reply-To: <071.359fe0f86ca1e93982adc7037842c911@localhost> References: <071.359fe0f86ca1e93982adc7037842c911@localhost> Message-ID: <080.183059f181f66754e423d616b4a357aa@localhost> #364: panic! ... forkM Declaration for tables{v} -------------------------+-------------------------------------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.4 Severity: normal | Resolution: Fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by mwassell@bigpond.net.au): * architecture: => Unknown * difficulty: => Unknown * testcase: => * os: => Unknown Comment: Sorry for the late reply. wferi's comment applies to me as well - the message about not finding the interface file is reasonable and clear - it is the panic that I was reporting (as requested at the end of the message). -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 1 22:04:02 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1406: Constraint doesn't reduce in the presence of quantified type variables Message-ID: <071.ebcbc7ef25d06b3b1081db5051bc3098@localhost> #1406: Constraint doesn't reduce in the presence of quantified type variables --------------------------------------+------------------------------------- Reporter: ccshan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: x86 --------------------------------------+------------------------------------- {{{ {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-undecidable-instances #-} module Problem where data Z data S a class HPrefix l instance (NSub (S Z) ndiff, HDrop ndiff l l) => HPrefix l class NSub n1 n3 | n1 -> n3 instance NSub Z Z instance NSub n1 n3 => NSub (S n1) n3 class HDrop n l1 l2 | n l1 -> l2 instance HDrop Z l l t_hPrefix :: HPrefix l => l -> () t_hPrefix = undefined -- This works... thr' :: (forall r. l -> a) -> a thr' f = f undefined thP4' = thr' t_hPrefix -- ... but this doesn't work...? thr :: (forall r. r -> a) -> a thr f = f undefined thP4 = thr t_hPrefix }}} {{{ $ ghci GHCProblem.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. [1 of 1] Compiling Problem ( GHCProblem.hs, interpreted ) GHCProblem.hs:30:11: No instance for (HDrop ndiff r r) arising from use of `t_hPrefix' at GHCProblem.hs:30:11-19 Possible fix: add (HDrop ndiff r r) to the expected type of an expression In the first argument of `thr', namely `t_hPrefix' In the expression: thr t_hPrefix In the definition of `thP4': thP4 = thr t_hPrefix Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Sat Jun 2 01:06:11 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files Message-ID: <071.9c68bb139fbbb7e23e9f735625ab5f11@localhost> #1407: Add the ability to :set -l{foo} in .ghci files ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: minor | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- Currently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ignored in both 6.4.2 and 6.6. The only other place it would make sense to pass it would be as something like OPTIONS_GHC, but that results in "unknown flags in {-# OPTIONS #-} pragma: -lidn" in 6.4.2 and appears to be silently ignored in 6.6. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Sun Jun 3 17:35:09 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.fd893159ef0b2a6417decd10a6f516b0@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by Isaac Dupree): Also grepping the source for __GLASGOW_HASKELL__ finds many things that need examining. Mostly it is "#if"s for compatibility with old versions of libraries that old versions of GHC have; for non-GHC compilers I think the best thing to do with these is to make sure it assumes the latest version of the libraries (old versions of ghc need to be able to compile new ones for a special reason, and the older versions also had more difficulty having upgradeable packages) -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Sun Jun 3 17:41:39 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.52799c2de7610d9c5a5e6beffe08408a@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Old description: > This depends a bit on the existence of a good-enough non-GHC compiler. > Possibility to do recursively dependent modules (I think) presently rules > out everything except JHC, which is not entirely working yet. Also > pattern guards might need to be implemented in that compiler. Maybe for > testing, a ghc that doesn't define __GLASGOW_HASKELL__ (and doesn't use > ghc-specific flags ??) could be used too. > > See http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962 ... GHC > also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that > everyone provides, but would still be good to document. > > I'm working on this now, we'll see how far I get --Isaac New description: This depends a bit on the existence of a good-enough non-GHC compiler. Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet. Also pattern guards might need to be implemented in that compiler. Maybe for testing, a ghc that doesn't define __GLASGOW_HASKELL__ (and doesn't use ghc-specific flags ?? possibly a wrapper script of some sort) could be used too. See http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962 ... GHC also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that everyone provides, but would still be good to document. I'm working on this now, we'll see how far I get --Isaac -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Sun Jun 3 17:49:42 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: =?utf-8?q?=5BGHC=5D_=231408=3A_groupWhen_=E2=80=93_a_groupBy_tha?= =?utf-8?q?t_compares_consecutive_values?= Message-ID: <071.baf524e5c57db4149a2746ac3e521817@localhost> #1408: groupWhen ? a groupBy that compares consecutive values ----------------------------------------------------------+----------------- Reporter: Joachim Breitner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Os: Unknown Testcase: | Architecture: Unknown ----------------------------------------------------------+----------------- `groupBy` has a minor problem: It always uses the first value of a group to decide whether a new value belongs to this group or the next. In several cases it would be more useful if it would take the last value of a group, thus always comparing consecutive values. Example code: {{{ groupWhen :: (a -> a -> Bool) -> [a] -> [[a]] groupWhen _ [] = [] groupWhen _ [a] = [[a]] groupWhen f (a:l) = if f a (head c) then (a:c):r else [a]:c:r where (c:r) = groupWhen f l }}} Uses: {{{ groupWhen (\a b -> b - a < 5) [1,2,4,10,14,16,18] -- Finding holes in a increasing series, e.g. log time stamps (my real use case) }}} or {{{ groupWhen (<) [1,2,3,2,10,12,10,11] -- Group into strictly increasing sublists }}} Note that for transitive and symetrical comparision functions `f` (such as `(==)`), `groupBy f == groupWhen f`. It should probably go to Data.List -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Sun Jun 3 17:52:02 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA4OiBncm91cFdoZW4g4oCTIGEgZ3JvdXBC?= =?utf-8?q?y_that_compares_consecutive_values?= In-Reply-To: <071.baf524e5c57db4149a2746ac3e521817@localhost> References: <071.baf524e5c57db4149a2746ac3e521817@localhost> Message-ID: <080.8a0b7989b086e87fb67a258628f194c6@localhost> #1408: groupWhen ? a groupBy that compares consecutive values ------------------------------------------------------------+--------------- Reporter: Joachim Breitner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | ------------------------------------------------------------+--------------- Comment (by Joachim Breitner ): More comments and other implementations on http://hpaste.org/141 -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Sun Jun 3 18:18:50 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.d57a4760c4af290de16c132b128c9ed7@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by Isaac Dupree): Hmm, looking again, it does look like GHC's code sometimes uses unboxed stuff and imports GHC.stuff. Some of the places at least, it seems there's really no excuse for doing so... I can change those (at least if I feel sure there are no performance regressions thereby). -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Mon Jun 4 03:52:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.be4cd5d7978c3bf9da3ab2c832f947af@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by simonpj): The other thing to watch out for is that we keep GHC in a state in which it can be compiled by several '''earlier''' versions of GHC. I forget what our current earlier-version threshold is (Simon M would know), but in doing your refactoring please be careful to maintain this property. We don't want to pull up the ladder after ourselvese too quickly! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Mon Jun 4 05:24:27 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1379: Panic in new debugging tools In-Reply-To: <071.424da12e2e271218a82dfc30dc1282f7@localhost> References: <071.424da12e2e271218a82dfc30dc1282f7@localhost> Message-ID: <080.c97a22ffd9933639ec7ef5998c27d745@localhost> #1379: Panic in new debugging tools ---------------------------------+------------------------------------------ Reporter: Michael D. Adams | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8 Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Mon Jun 4 09:42:29 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) Message-ID: <071.e07afc7430d51afefe4156e399c5f77d@localhost> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) ------------------------------+--------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- Essentially, compile strongly-connected sets of modules like single modules are compiled (they have to have the same default and monomorphism- restriction, so it is like compiling one module, after the module/import fixpoint and name resolution are done). This can increase the amount of recompilation necessary compared to using .hs-boot files, so it is probably desirable to still allow those. Of course, manually keeping .hs-boot files and {-#SOURCE#-} pragmas around (and synchronized with the real code) is a nuisance (though informative if one cares about minimizing the amount of recursion). I suspect that there can be situations where one level of export-subsets via .hs-boot files is not sufficient... (which would be one reason it wouldn't be easy to "just" treat a subset of each .hs file as its .hs-boot). When not using --make mode, ghc would have to find the minimal module cycles somehow, and put just one ".hi-boots" or ".his", and .o I think, file somewhere (next to an arbitrary one of the modules I guess) in order that the compilation isn't repeated pointlessly for each module. And deal with which compiler flags are used. Maybe better not to allow it without --make. In --make mode, such hackery should not be needed. This might also help deal with (work around?) such existing bugs with recursive modules and --make: #930 , #1072 , #1133 . The modules having different OPTIONS_GHC or LANGUAGE pragmas might still be tricky or impossible to accept, depending which ones they are and how much implementation effort it's worth investing in allowing that. (Although, class instances being overlappable might be advantageous to have implemented a per-class not per-module specification anyway, for example, so pragmas that affect less than the whole module could be added more easily.) -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Mon Jun 4 10:15:19 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.28c166bf20125707365a4d429fabc36c@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by Isaac Dupree): Yes, certainly, I think it's ghc-5.04 currently. Is there an easy way to get a copy of that version of ghc (or other versions between that and the current) to test with? Or should I just rely on my intuition while watching for buildbots breaking that use old versions of ghc? I think it's okay if GHC is merely slower when compiled with older versions of GHC (since normally you'll be using recent GHC for development, and stage2, anyway), for example if older versions of GHC optimized worse or didn't implement UNPACK pragma... -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Mon Jun 4 10:44:06 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1402: panic in GHC when building QuickCheck with optimization In-Reply-To: <071.20f91518043ad5301ba7bfdcd1282607@localhost> References: <071.20f91518043ad5301ba7bfdcd1282607@localhost> Message-ID: <080.399e008f6a7c27f83196761eb3837a2c@localhost> #1402: panic in GHC when building QuickCheck with optimization -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by simonpj): Dear cdsmith We'd like to reproduce this. But `darcs.haskell.org/packages/QuickCheck` doesn't have `Test.QuickCheck.Gen`. So, can you send us a repo case? Ideally, boiled down, but if you can't face that, then just a blob of files and build instructions. If you put yourself in the cc field of this bug report, you'll see these updates. As it is, we have no way to contact you! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Mon Jun 4 12:29:13 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1402: panic in GHC when building QuickCheck with optimization In-Reply-To: <071.20f91518043ad5301ba7bfdcd1282607@localhost> References: <071.20f91518043ad5301ba7bfdcd1282607@localhost> Message-ID: <080.aef89a5e570d78f1a366acfe6e957e2b@localhost> #1402: panic in GHC when building QuickCheck with optimization -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by guest): * cc: => cdsmith@twu.net -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Mon Jun 4 17:34:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1393: Tag source tree with successful bootstraps In-Reply-To: <071.1bfa7193b580f545578173a428dce2f9@localhost> References: <071.1bfa7193b580f545578173a428dce2f9@localhost> Message-ID: <080.4d26a5a1d251e88e4b9540d55411a311@localhost> #1393: Tag source tree with successful bootstraps ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 6.7 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Comment (by AndyGill): TO build on SimonM's 05/30/07 13:13:33 comments: We could also use a staging repo * At a specific time, every patch is pulled from darcs/ghc to darcs/staging_/ghc (same with the related repos for the libraries) * The buildbots build from the staging versions. * If a version builds and tests ok, we change the name of the repo from staging_ to stable_ * We publish a list of the stable repos. Changes still go back into HEAD. We definitely do need to overall things a bit; no stable builds and pulling in every patch every time for developers are a huge overhead. Andy Gill -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 00:04:17 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:43 2007 Subject: [GHC] #1410: Control.Monad.Reader documentation Message-ID: <071.9ecac9f775c7fe156d6c9aff644506db@localhost> #1410: Control.Monad.Reader documentation --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Multiple Testcase: | Architecture: Multiple --------------------------------+------------------------------------------- Added Haddock documentation. Converted the existing module documentation to Haddock format. Created examples. Per Jeff Newberns permission included parts his tutorial "All About Monads" http://haskell.org/all_about_monads/. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 00:08:51 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1410: Control.Monad.Reader documentation In-Reply-To: <071.9ecac9f775c7fe156d6c9aff644506db@localhost> References: <071.9ecac9f775c7fe156d6c9aff644506db@localhost> Message-ID: <080.988c5bb55006bfd2fae8d066b90fde67@localhost> #1410: Control.Monad.Reader documentation ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | ----------------------------------+----------------------------------------- Comment (by guest): Deadline - 2 weeks - June 19, 2007 -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 02:45:09 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1411: Typo in type error for lazy patterns Message-ID: <071.08ab4747eb1f9931b4667d9bb73e7b2f@localhost> #1411: Typo in type error for lazy patterns --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Keywords: typo Difficulty: Easy (1 hr) | Os: Multiple Testcase: | Architecture: Multiple --------------------------------------+------------------------------------- There's a small typo in one of the type-error messages for lazy patterns. I've attached a patch that fixes it. [Corrected typo in compiler/typecheck/TcPat.lhs: stefan@cs.uu.nl**20070601054931 * connot ===> cannot ] { hunk ./compiler/typecheck/TcPat.lhs 958 - hang (ptext SLIT("A lazy (~) pattern connot bind existential type variables ")) + hang (ptext SLIT("A lazy (~) pattern cannot bind existential type variables ")) } -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 02:45:23 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1412: Typo in type error for lazy patterns Message-ID: <071.2a7cfeb36cc5e4db26503ffd8e548c12@localhost> #1412: Typo in type error for lazy patterns --------------------------------------+------------------------------------- Reporter: stefan@cs.uu.nl | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Keywords: typo Difficulty: Easy (1 hr) | Os: Multiple Testcase: | Architecture: Multiple --------------------------------------+------------------------------------- There's a small typo in one of the type-error messages for lazy patterns. I've attached a patch that fixes it. [Corrected typo in compiler/typecheck/TcPat.lhs: stefan@cs.uu.nl**20070601054931 * connot ===> cannot ] { hunk ./compiler/typecheck/TcPat.lhs 958 - hang (ptext SLIT("A lazy (~) pattern connot bind existential type variables ")) + hang (ptext SLIT("A lazy (~) pattern cannot bind existential type variables ")) } -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From stefan at cs.uu.nl Tue Jun 5 02:46:31 2007 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1412: Typo in type error for lazy patterns In-Reply-To: <071.2a7cfeb36cc5e4db26503ffd8e548c12@localhost> References: <071.2a7cfeb36cc5e4db26503ffd8e548c12@localhost> Message-ID: My apologies for the duplicated ticket; I ran into a database lock... On Jun 5, 2007, at 8:45 AM, GHC wrote: > #1412: Typo in type error for lazy patterns > -------------------------------------- > +------------------------------------- > Reporter: stefan@cs.uu.nl | Owner: > Type: bug | Status: new > Priority: low | Milestone: > Component: Compiler (Type checker) | Version: 6.7 > Severity: normal | Keywords: typo > Difficulty: Easy (1 hr) | Os: Multiple > Testcase: | Architecture: Multiple > -------------------------------------- > +------------------------------------- > There's a small typo in one of the type-error messages for lazy > patterns. > I've attached a patch that fixes it. > > [Corrected typo in compiler/typecheck/TcPat.lhs: > stefan@cs.uu.nl**20070601054931 > * connot ===> cannot > ] { > hunk ./compiler/typecheck/TcPat.lhs 958 > - hang (ptext SLIT("A lazy (~) pattern connot bind existential > type > variables > ")) > + hang (ptext SLIT("A lazy (~) pattern cannot bind existential > type > variables > ")) > } > > -- > Ticket URL: > GHC > The Glasgow Haskell > Compiler_______________________________________________ > 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 From trac at galois.com Tue Jun 5 04:36:21 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <071.bd4ae66865d4330446a06eaf62a80a52@localhost> References: <071.bd4ae66865d4330446a06eaf62a80a52@localhost> Message-ID: <080.d5db3044b8265351abacc79fdf98c92b@localhost> #1110: Setting PATH needed in Windows Vista ------------------------------------+--------------------------------------- Reporter: br1@internet.com.uy | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.8 Component: Driver | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Windows | Testcase: Architecture: x86_64 (amd64) | ------------------------------------+--------------------------------------- Changes (by simonmar): * resolution: => fixed * status: reopened => closed Comment: Now fixed. {{{ Fri Jun 1 16:19:32 BST 2007 Simon Marlow * FIX #1110: the linker also needs the workaround }}} -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 04:45:34 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1379: Panic in new debugging tools In-Reply-To: <071.424da12e2e271218a82dfc30dc1282f7@localhost> References: <071.424da12e2e271218a82dfc30dc1282f7@localhost> Message-ID: <080.00529820226da8c52f7174bd029d89fb@localhost> #1379: Panic in new debugging tools ---------------------------------+------------------------------------------ Reporter: Michael D. Adams | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10 Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.8 => 6.10 * priority: high => normal * type: bug => feature request Comment: I fixed the panic, but it's still not possible to do what you wanted to do, namely set a breakpoint on a function defined interactively. I'll leave that as a feature request, since it's not straightforward to implement right now. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 05:02:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1412: Typo in type error for lazy patterns In-Reply-To: <071.2a7cfeb36cc5e4db26503ffd8e548c12@localhost> References: <071.2a7cfeb36cc5e4db26503ffd8e548c12@localhost> Message-ID: <080.2976c040b0a66754a3735b4ec33eb96b@localhost> #1412: Typo in type error for lazy patterns ----------------------------------------+----------------------------------- Reporter: stefan@cs.uu.nl | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: duplicate Keywords: typo | Difficulty: Easy (1 hr) Os: Multiple | Testcase: Architecture: Multiple | ----------------------------------------+----------------------------------- Changes (by simonmar): * resolution: => duplicate * status: new => closed Comment: #1411 -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 11:11:32 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1402: panic in GHC when building QuickCheck with optimization In-Reply-To: <071.20f91518043ad5301ba7bfdcd1282607@localhost> References: <071.20f91518043ad5301ba7bfdcd1282607@localhost> Message-ID: <080.7d9e41605979a4da62c5beb78f1eca17@localhost> #1402: panic in GHC when building QuickCheck with optimization -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by cdsmith@twu.net): Hmm. It appears that I grabbed http://darcs.haskell.org/QuickCheck/ instead of http://darcs.haskell.org/packages/QuickCheck/. I don't know what the difference is. I'll tar up the directory and attach it. I hope that's what you mean by a repo case. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 15:22:24 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1413: copyFile: atomicity docs/code mismatch Message-ID: <071.4c1b34073951322aef5fc96bb611a79a@localhost> #1413: copyFile: atomicity docs/code mismatch -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------------+---------------------------------------------- http://haskell.org/ghc/docs/latest/html/libraries/base/System- Directory.html#v%3AcopyFile says: copyFile old new copies the existing file from old to new. If the new file already exists, it is ''atomically replaced'' by the old file. Neither path may refer to an existing directory. The permissions of old are copied to new, if possible. AFAIK the only way to do atomic replacement is to write to a temporary file, then rename it over the target. However, strace shows that copyFile does open(), ftruncate(), then multiple write()s; this is clearly not atomic. Conclusion: Either the docs or the code are wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 15:42:29 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.e4de181f943037347d256a8411fe2bd6@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by igloo): We abandoned 5.04 support recently as the differences in its hierarchical libraries compared to 6.x were causing too much pain. I think any 6.x is supposed to still work, though. Bindists are the simplest way of getting older versions, but you might have problems due to them being compiled against older libraries. If it proves tricky then just keeping an eye on the nightly builds is the way to go. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 15:49:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1411: Typo in type error for lazy patterns In-Reply-To: <071.08ab4747eb1f9931b4667d9bb73e7b2f@localhost> References: <071.08ab4747eb1f9931b4667d9bb73e7b2f@localhost> Message-ID: <080.5f54fa9a1c024821c851dc0866fb758c@localhost> #1411: Typo in type error for lazy patterns ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: typo | Difficulty: Easy (1 hr) Os: Multiple | Testcase: Architecture: Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Thanks for the report! Now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 16:04:45 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #477: Compiling multiple executables with -make In-Reply-To: <071.d6faedf96893cf7b6436522393bd3435@localhost> References: <071.d6faedf96893cf7b6436522393bd3435@localhost> Message-ID: <080.231707744ccd16a8f526b4b94ae05fb4@localhost> #477: Compiling multiple executables with -make --------------------------------+------------------------------------------- Reporter: supermule | Owner: nobody Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Os: Unknown | Testcase: N/A Architecture: Unknown | --------------------------------+------------------------------------------- Changes (by guest): * resolution: None => invalid * status: assigned => closed Comment: Just ignore this report. The reason it felt so slow, had more to do with Emacs being slow at interpretating the compiler output than GHC being slow. Mads Lindstr?m -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 17:42:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1404: allow more type signatures In-Reply-To: <071.59d223f273558ac858eb9a3327d41678@localhost> References: <071.59d223f273558ac858eb9a3327d41678@localhost> Message-ID: <080.83ee4c5f9377ed96bbb1d67f585024e5@localhost> #1404: allow more type signatures ----------------------------------------+----------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------------+----------------------------------- Changes (by igloo): * component: Compiler => Compiler (Type checker) * milestone: => _|_ Comment: You can do (1) with {{{ foo :: type #if ... foo = ... #else foo = ... #endif }}} (2) doesn't seem that useful to me personally. Type sigs in export lists might be nice, as some people seem to like giving them as comments which then get out of sync with the actual types. It might be worth starting a discussion on the Haskell' list about all this. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 17:51:02 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.414b77410c8c4033c0622d3affde7dac@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by Isaac Dupree): OK, it's now 6.0 or greater (according to http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites ). Is it preferred, discouraged or neither, to remove {{{#if __GLASGOW_HASKELL__ > 5.04}}} sorts of checks in the code now? -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 17:59:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.bf43a64a25c7b7a3383b2388ee072e16@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by igloo): Yup, please do remove any such checks. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 18:27:46 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1372: Recompilation checker should consider package versions (and other factors) In-Reply-To: <071.e047166ac778d0984cec10f693b8b038@localhost> References: <071.e047166ac778d0984cec10f693b8b038@localhost> Message-ID: <080.07b6677ab6b933db14a8db4aba56a24d@localhost> #1372: Recompilation checker should consider package versions (and other factors) -------------------------+-------------------------------------------------- Reporter: bringert | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by igloo): I'm not entirely sure I understand correctly, but I think that what you propose will mean that with GHC's current build system we'll rebuild all the libraries (except base) when you do "make" in a built tree, as we do (roughly) "setup/Setup build && setup/Setup register --inplace" for each library in turn. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 18:42:45 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.55972d8933ed372850b18b29f8a23bef@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by Isaac Dupree): Should such checks for really old ghc also be removed in the various ghc/utils programs? -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 19:00:02 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1414: CString marshalling functions do not perform the specified conversion Message-ID: <071.612c836363c32b6166b52d3a71b8becc@localhost> #1414: CString marshalling functions do not perform the specified conversion -----------------------------+---------------------------------------------- Reporter: ross | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.6.1 Severity: major | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------------+---------------------------------------------- The `CString` and `CStringLen` marshalling functions are specified in the FFI addendum as performing a locale-based conversion, but this is not implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 19:04:15 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1395: let ./configure check for a GNUreadline framework In-Reply-To: <071.df826feb21fdb94aca2dca15f683ef86@localhost> References: <071.df826feb21fdb94aca2dca15f683ef86@localhost> Message-ID: <080.7547f4cfa95637868dad330be8ac361a@localhost> #1395: let ./configure check for a GNUreadline framework --------------------------------+------------------------------------------- Reporter: maeder@tzi.de | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: MacOS X | Testcase: Architecture: Multiple | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: 6.6.2 => 6.8 Comment: We're using the 6.6.2 milestone for bugs that will only be done if we decide to do 6.6.2 after all. This sounds like 6.8 should have it too, so I'm remilestoning it; feel free to put it back if I'm wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 19:07:08 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> References: <071.fbfe0a1d230a6fdf42f2ab00636cdcba@localhost> Message-ID: <080.70ef449ccac7a29846c996deda5c38ac@localhost> #1405: Make ghc (stage1) be compilable by non-GHC -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by igloo): Support for building with old GHCs, yes. Support for things like looking at the output of old GHCs, possibly not. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue Jun 5 19:13:41 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1415: Provide a way to runInteractiveCommand without passing all your filedescriptors Message-ID: <071.53723404b39d5577498b1c130375c4ab@localhost> #1415: Provide a way to runInteractiveCommand without passing all your filedescriptors --------------------------------+------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: libraries (other) | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- We should make it easy for people to write secure programs, and currently it's non-trivial to run another program without giving it all of your file descriptors etc. See the thread starting http://www.haskell.org/pipermail/libraries/2007-June/007566.html -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 03:56:26 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1413: copyFile: atomicity docs/code mismatch In-Reply-To: <071.4c1b34073951322aef5fc96bb611a79a@localhost> References: <071.4c1b34073951322aef5fc96bb611a79a@localhost> Message-ID: <080.053af9f955fd4cb3374c2eca4d8f0be3@localhost> #1413: copyFile: atomicity docs/code mismatch -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------+-------------------------------------------- Comment (by simonmar): See also #873 -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 04:12:05 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1372: Recompilation checker should consider package versions (and other factors) In-Reply-To: <071.e047166ac778d0984cec10f693b8b038@localhost> References: <071.e047166ac778d0984cec10f693b8b038@localhost> Message-ID: <080.e60e52f6bc90e3dde74ccfc83590f69d@localhost> #1372: Recompilation checker should consider package versions (and other factors) -------------------------+-------------------------------------------------- Reporter: bringert | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by simonmar): Yes, registering a package would cause all the dependent packages to be recompiled. In the case of the GHC build system that may not be what you want. Perhaps we can avoid re-registering if nothing was recompiled and the package is already registered. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 04:16:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1379: Allow breakpoints and single-stepping for functions defined interactively In-Reply-To: <071.424da12e2e271218a82dfc30dc1282f7@localhost> References: <071.424da12e2e271218a82dfc30dc1282f7@localhost> Message-ID: <080.2ac6de335935fb595a8ce551d7e7d507@localhost> #1379: Allow breakpoints and single-stepping for functions defined interactively ---------------------------------+------------------------------------------ Reporter: Michael D. Adams | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10 Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | ---------------------------------+------------------------------------------ Changes (by simonmar): * summary: Panic in new debugging tools => Allow breakpoints and single- stepping for functions defined interactively -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 05:15:25 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1416: Testsuite doesn't always work on MSYS with Cygwin Python Message-ID: <071.212a75f7fa8dc34cb2f06a6b95e3003e@localhost> #1416: Testsuite doesn't always work on MSYS with Cygwin Python -----------------------+---------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- '''Problem 1'''. Using the Cygwin Python. `testsuite/mk/test.mk` makes the GHC into `ghc-inplace.bat`. But `testlib.py` (the `runCmd` procedure) invokes `timeout`, which always calls a Bourne shell, so `ghc-inplace.bat` doesn't work. The timeout program must use a Bourne shell, because `testlib.py` often passes it a complex command in Bourne shell syntax. Current workaound: in `testsuite\mk\test.mk` disable the windows-specific setting of the GHC paths. '''IDEA''': it's a mess having a `ghc-inplace` shell script ''and'' a `ghc-inplace.bat` script. Instead we should have one executable, which we can invoke from anywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 05:16:53 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1416: Testsuite doesn't always work on MSYS with Cygwin Python In-Reply-To: <071.212a75f7fa8dc34cb2f06a6b95e3003e@localhost> References: <071.212a75f7fa8dc34cb2f06a6b95e3003e@localhost> Message-ID: <080.48c4bee21653b69b95f3e1dd616882fe@localhost> #1416: Testsuite doesn't always work on MSYS with Cygwin Python -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Old description: > '''Problem 1'''. Using the Cygwin Python. `testsuite/mk/test.mk` makes > the GHC into `ghc-inplace.bat`. But `testlib.py` (the `runCmd` > procedure) invokes `timeout`, which always calls a Bourne shell, so `ghc- > inplace.bat` doesn't work. > > The timeout program must use a Bourne shell, because `testlib.py` often > passes it a complex command in Bourne shell syntax. > > Current workaound: in `testsuite\mk\test.mk` disable the windows-specific > setting of the GHC paths. > > '''IDEA''': it's a mess having a `ghc-inplace` shell script ''and'' a > `ghc-inplace.bat` script. Instead we should have one executable, which > we can invoke from anywhere. New description: '''Problem 1'''. Using the Cygwin Python. `testsuite/mk/test.mk` makes the GHC into `ghc-inplace.bat`. But `testlib.py` (the `runCmd` procedure) invokes `timeout`, which always calls a Bourne shell, so `ghc-inplace.bat` doesn't work. The timeout program must use a Bourne shell, because `testlib.py` often passes it a complex command in Bourne shell syntax. Current workaound: in `testsuite\mk\test.mk` disable the windows-specific setting of the GHC paths. '''IDEA''': it's a mess having a `ghc-inplace` shell script ''and'' a `ghc-inplace.bat` script. Instead we should have one executable, which we can invoke from anywhere. ''PS'' Why should we care about Cygwin Python and MSYS? Well, it's exposed a fragility with this ghc-inplace stuff; and the testsuite doesn't work with native Python under MSYS either. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 08:00:10 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA4OiBncm91cFdoZW4g4oCTIGEgZ3JvdXBC?= =?utf-8?q?y_that_compares_consecutive_values?= In-Reply-To: <071.baf524e5c57db4149a2746ac3e521817@localhost> References: <071.baf524e5c57db4149a2746ac3e521817@localhost> Message-ID: <080.884af027b45cbfb4e661744c4d258ed4@localhost> #1408: groupWhen ? a groupBy that compares consecutive values ------------------------------------------------------------+--------------- Reporter: Joachim Breitner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | ------------------------------------------------------------+--------------- Changes (by ross): * component: libraries (other) => libraries/base Comment: The Haskell 98 Report (s17.6) says "When the `By` function replaces an `Eq` context by a binary predicate, the predicate is assumed to define an equivalence". Since the new function agrees with `groupBy` in that case, I think it would be reasonable to redefine `groupBy` as this more useful version. The same applies to `nubBy`, and possibly `deleteBy`, `deleteFirstsBy` and `intersectBy` (which could have more general types to make this clear). On the downside, it would mess up the simple uniform treatment of the `By` functions. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 09:11:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1385: (1,True) == (2,False) doesn't compile In-Reply-To: <071.1f92f3eb3189c51f6512bfe23499d94a@localhost> References: <071.1f92f3eb3189c51f6512bfe23499d94a@localhost> Message-ID: <080.163dfc513d3b00a64be19d07900977c8@localhost> #1385: (1,True) == (2,False) doesn't compile ----------------------------------------+----------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: tc049, tc227 Architecture: Unknown | ----------------------------------------+----------------------------------- Changes (by simonpj): * resolution: => fixed * testcase: tc049 => tc049, tc227 * status: new => closed Comment: Good report; now fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 09:37:12 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1398: -fno-monomorphism-restriction suggested when not appropriate In-Reply-To: <071.8d0661d89551418025d30833ca277d6a@localhost> References: <071.8d0661d89551418025d30833ca277d6a@localhost> Message-ID: <080.7612b9ef9ee30862f865a1eb732cf70d@localhost> #1398: -fno-monomorphism-restriction suggested when not appropriate ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by simonpj): * resolution: => fixed * status: new => closed Comment: Good idea. Done. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 10:09:06 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1402: panic in GHC when building QuickCheck with optimization In-Reply-To: <071.20f91518043ad5301ba7bfdcd1282607@localhost> References: <071.20f91518043ad5301ba7bfdcd1282607@localhost> Message-ID: <080.bef32245ef021c19bdbd7bd460a05a61@localhost> #1402: panic in GHC when building QuickCheck with optimization -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by simonpj): Excellent. I've boiled it down to a 3-line program that crashes the HEAD with -O {{{ newtype Gen a = MkGen{ unGen :: Int -> a } choose :: Eq a => a -> Gen a choose n = MkGen (\r -> n) oneof = choose (1::Int) }}} Need to investigate further, but this is progress. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 10:10:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1398: -fno-monomorphism-restriction suggested when not appropriate In-Reply-To: <071.8d0661d89551418025d30833ca277d6a@localhost> References: <071.8d0661d89551418025d30833ca277d6a@localhost> Message-ID: <080.d20e16ea361dfb3dcccc97b1d985516e@localhost> #1398: -fno-monomorphism-restriction suggested when not appropriate ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by Isaac Dupree): Hopefully it doesn't recommend -fno-monomorphism-restriction in those same cases if the flag *wasn't* passed to ghc (because it won't help...) -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 11:06:51 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1398: -fno-monomorphism-restriction suggested when not appropriate In-Reply-To: <071.8d0661d89551418025d30833ca277d6a@localhost> References: <071.8d0661d89551418025d30833ca277d6a@localhost> Message-ID: <080.147b16f182890c2909f02456ade28f33@localhost> #1398: -fno-monomorphism-restriction suggested when not appropriate ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by simonpj): I don't understand. All I've done is make sure you don't get a suggestion to do something you have already done. There is no claim that the suggestion will necessarily make things work even if you follow it! S -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 20:57:35 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1417: Add pseudoterminal support to the unix package Message-ID: <071.f74184c32fb42c392c45693816561b53@localhost> #1417: Add pseudoterminal support to the unix package ---------------------------------+------------------------------------------ Reporter: bos@serpentine.com | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ---------------------------------+------------------------------------------ I propose to enhance the unix package by adding pty support: -- | @openPseudoTerminal@ creates a pseudoterminal (pty) pair, and -- returns the newly created pair as a (@master@, @slave@) tuple. openPseudoTerminal :: IO (Fd, Fd) -- | @getSlaveTerminalName@ calls @ptsname@ to obtain the name of the -- slave terminal associated with a pseudoterminal pair. The file -- descriptor to pass in must be that of the master. getSlaveTerminalName :: Fd -> IO FilePath This is all that's required to get pseudoterminals working on Unix-like systems. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 21:00:34 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1417: Add pseudoterminal support to the unix package In-Reply-To: <071.f74184c32fb42c392c45693816561b53@localhost> References: <071.f74184c32fb42c392c45693816561b53@localhost> Message-ID: <080.018b1fd02f2e320b63f1d9915b9c4b8a@localhost> #1417: Add pseudoterminal support to the unix package -----------------------------------+---------------------------------------- Reporter: bos@serpentine.com | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------------+---------------------------------------- Comment (by bos@serpentine.com): The code ought to work on Linux, Solaris, BSD, and HP/UX. Probably Cygwin, too. However, I've only been able to compile-test it on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed Jun 6 21:02:55 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1326: Bindings for POSIX named semaphores and shared memory objects In-Reply-To: <071.37b2f3b9aa1620023de79cc1dcdd4c1b@localhost> References: <071.37b2f3b9aa1620023de79cc1dcdd4c1b@localhost> Message-ID: <080.be81713c94eaa27ea69a235da590c766@localhost> #1326: Bindings for POSIX named semaphores and shared memory objects -------------------------------+-------------------------------------------- Reporter: dfranke | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -------------------------------+-------------------------------------------- Changes (by bos@serpentine.com): * resolution: => fixed * status: new => closed Comment: This change is now in the darcs repo. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu Jun 7 05:26:07 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1418: Heap profiling woes Message-ID: <071.934356636ad6660da2c19207413a6ab3@localhost> #1418: Heap profiling woes ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 ------------------------+--------------------------------------------------- I have a large program with a space leak. So I want to heap profiling, of course. Here's what happens: I compile with -prof -auto-all and run with -hc. All (99%) allocation is attributed to Main.CAF. I add -caf-all, run with -hc. All allocation is attributed to Main.main. I try running with -hd. The program segfaults. I try running with -hy. The program segfaults. I try running with -hb. The program dies with a GHC RTS internal error. I try running with -hr. The generated profile cannot be read by hp2ps because it's truncated. I edit the truncated file by hand. The allocation is now split between main and SYSTEM. -- Lennart -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu Jun 7 05:31:44 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1254: truncate = float2Int rule is incorrect In-Reply-To: <071.8a7983eaf7cb8e30ced95708a7370b30@localhost> References: <071.8a7983eaf7cb8e30ced95708a7370b30@localhost> Message-ID: <080.dfe01cf94c70390e658500b980abc862@localhost> #1254: truncate = float2Int rule is incorrect -----------------------------------+---------------------------------------- Reporter: brian@brianweb.net | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.8 Component: libraries/base | Version: 6.7 Severity: minor | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Multiple | Testcase: arith005 Architecture: powerpc | -----------------------------------+---------------------------------------- Changes (by simonmar): * milestone: _|_ => 6.8 * testcase: => arith005 Comment: There's more: float2Int# is implemented in the C backend as a cast. The C spec does not define the result of the cast when the result would be outside the range of the destination type, so we get unpredictable results. The Haskell report doesn't say what should happen in the case of `truncate` when the result doesn't fit, and the description for `properFraction` doesn't either. Therefore I guess the result is undefined for Haskell 98, we should clarify for Haskell'. Bottom line: I think the test should be fixed (arith005), and this isn't a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu Jun 7 05:47:40 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:44 2007 Subject: [GHC] #1417: Add pseudoterminal support to the unix package In-Reply-To: <071.f74184c32fb42c392c45693816561b53@localhost> References: <071.f74184c32fb42c392c45693816561b53@localhost> Message-ID: <080.fe435ea0a8d31d1f3a9cbad2abad4918@localhost> #1417: Add pseudoterminal support to the unix package -----------------------------------+---------------------------------------- Reporter: bos@serpentine.com | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------------+---------------------------------------- Comment (by simonmar): No objection in principle; the code does stuff I don't understand so I won't claim to have fully reviewed it though. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From frederik at a5.repetae.net Thu Jun 7 09:01:04 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Jul 19 09:48:44 2007 Subject: release notes Message-ID: <20070607130104.GA32571@a5.repetae.net> Hello, Perhaps it's a bit late, but should the release notes for 6.6.1 mention that many libraries have been split off from the main package (at least in the Debian version)? I am looking here: /usr/share/doc/ghc6/changelog.Debian.gz and here: http://haskell.org/ghc/docs/6.6.1/html/users_guide/release-6-6-1.html and I don't see anything. Thanks, Frederik _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From frederik at a5.repetae.net Thu Jun 7 12:57:22 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Jul 19 09:48:45 2007 Subject: release notes In-Reply-To: <466822E5.1000500@gmail.com> References: <20070607130104.GA32571@a5.repetae.net> <466822E5.1000500@gmail.com> Message-ID: <20070607165722.GI24830@a5.repetae.net> OK I see, I was switching from a ghc-6.6.20070420 binary release to the Debian package. I must have installed the 'extralibs' package or something together with the former...? Frederik On Thu, Jun 07, 2007 at 04:23:17PM +0100, Simon Marlow wrote: > Frederik Eaton wrote: > >Hello, > >Perhaps it's a bit late, but should the release notes for 6.6.1 > >mention that many libraries have been split off from the main package > >(at least in the Debian version)? > >I am looking here: > >/usr/share/doc/ghc6/changelog.Debian.gz > >and here: > >http://haskell.org/ghc/docs/6.6.1/html/users_guide/release-6-6-1.html > >and I don't see anything. > > That change happened in version 6.6, you'll see it in the 6.6 release notes. Incedentally, I think the 6.6.1 > manual should have contained the 6.6 release notes too, perhaps that was an oversight. > > Cheers, > Simon > -- http://ofb.net/~frederik/ _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 8 04:55:03 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:45 2007 Subject: [GHC] #1419: "GHC as a library" stalls when nobody is consuming it's output Message-ID: <071.9fd5811e56a0d3af42d1b2a5cad1b86b@localhost> #1419: "GHC as a library" stalls when nobody is consuming it's output -----------------------+---------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: GHC API | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- Reported by Mads Lindstr?m on glasgow-haskell- users: While trying to implement a GUI for GHCi, I have run into an annoying concurrency problems. I think "GHC as a library" is at fault, as it stalls (maybe some deadlock) when nobody is consuming it's output. This message is a literate Haskell program, which illustrates the problem. This test-program starts a thread which prints an 'A' on stderr every second. Then it wait three seconds (meanwhile the 'A's are printing), and runs, via "GHC as a library", the following Haskell code "[1..]". If I start the program as: {{{ ./IsGhcBlocking >/dev/null }}} everything works fine and the 'A' keeps coming out on stderr. However, if I do: {{{ ./IsGhcBlocking | sleep 10 }}} I only see three 'A's. I believe that is because the sleep-command, do not consume any input. The program was tested on Debian Etch running GHC 6.6. {{{ > module Main where > Compile with: ghc -threaded -package ghc-6.6 --make IsGhcBlocking.lhs > import qualified GHC as GHC > import qualified Outputable as GHC > import qualified Packages as GHC > import qualified DynFlags as GHC > import qualified ErrUtils as GHC > > import System.IO > import Control.Concurrent > -- the path of our GHC 6.6 installation > path :: FilePath > -- path = "c:\\ghc-6.6" > path = "/usr/lib/ghc-6.6/" > > main :: IO() > main = do let printAs = do threadDelay (10^6) > hPutStrLn stderr "A" > printAs > forkOS printAs -- forkIO gives the same result > threadDelay (10^6 * 3) > session <- initializeSession > GHC.runStmt session "[1..]" > return () > > initializeSession = > do session <- GHC.newSession GHC.Interactive (Just path) > > -- initialize the default packages > dflags0 <- GHC.getSessionDynFlags session > let myLogAction _ locSpec style errMsg = hPutStrLn stderr showMsg where > showMsg = GHC.showSDoc $ GHC.withPprStyle style $ GHC.mkLocMessage locSpec errMsg > dflags1 = dflags0 { GHC.log_action = myLogAction } > (dflags2, packageIds) <- GHC.initPackages dflags1 > GHC.setSessionDynFlags session dflags2{GHC.hscTarget=GHC.HscInterpreted} > GHC.setContext session [] [] > return session }}} The stalling becomes a problem, when one wants to interrupt "GHC as a library"'s runStmt function. One could interrupt "GHC as a library" with Panic.interruptTargetThread (see http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/12289). However, as "GHC as a library" locks up (stalls, deadlocks) there is no way of executing Panic.interruptTargetThread. Some people may suggest that I should always consume the output from "GHC as a library". But that is easier said than done. Many GUI libraries (including !WxHaskell, which I am using) only allows for one active thread at a time (see http://wxhaskell.sourceforge.net/faq.html). Thus my GUI cannot simultaneously tell "GHC as a library" to interrupt it's execution and read it's output. For thus wondering how I can run both a GUI and "GHC as a library", if !WxHaskell is not happy about threading, the answer is that I run the GUI and "GHC as a library" in separate processes. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri Jun 8 04:55:10 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:45 2007 Subject: [GHC] #1419: "GHC as a library" stalls when nobody is consuming it's output In-Reply-To: <071.9fd5811e56a0d3af42d1b2a5cad1b86b@localhost> References: <071.9fd5811e56a0d3af42d1b2a5cad1b86b@localhost> Message-ID: <080.a6033f959f2538c1d9edea8f58c98820@localhost> #1419: "GHC as a library" stalls when nobody is consuming it's output -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8 Component: GHC API | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar):