[ ghc-Bugs-1232660 ] Warning and glagow-exts instead of glasgow-exts
Bugs item #1232660, was opened at 2005-07-05 10:26 Message generated for change (Settings changed) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1232660group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Simon Peyton Jones (simonpj) Summary: Warning and glagow-exts instead of glasgow-exts Initial Comment: Take this module (Bla.hs): x = [ q | y - [1..10] | z - [30..40], let q = z*z] Loading it into GHCi gives: [ Bla.hs:1: Illegal parallel list comprehension: use - fglagow-exts ] PROBLEM: glagow-exts should be glasgow-exts If we supply this option, one of the warnings is incorrect: [ Bla.hs:1: Warning: Defined but not used: y, z ] PROBLEM: z is used but marked as not used Cheers, Arjan ([EMAIL PROTECTED]) -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-07-11 10:24 Message: Logged In: YES user_id=50165 Thank you. Both bugs now fixed. Test is rn047 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1232660group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-807249 ] Instance match failure on openTypeKind
Bugs item #807249, was opened at 2003-09-16 16:37 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=807249group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: None Status: Open Resolution: None Priority: 6 Submitted By: Simon Peyton Jones (simonpj) Assigned to: Simon Peyton Jones (simonpj) Summary: Instance match failure on openTypeKind Initial Comment: Consider instance Show (a-gt;b) where ... foo x = show (\ _ -gt; True) This fails with: No instance for (Show (t -gt; Bool)) arising from use of `show' at Foo.hs:5 Reason: the type of (\_ -gt; True) is (t -gt; Bool) where t has an quot;openTypeKindquot;. It's possible that the function will be applied to say an Int#, and the openTypeKind records that this is OK. BUT, the instance decl Show (a-gt;b) has a::liftedTypeKind, and that doesn't match an openTypeKind type variable. This bug relates to GHC's unsatisfactory treatment of the variants of kind quot;typequot;, for which there are at least 2 other SourceForge bugs registered (753780 and 753777). It's very obscure, so I'm not going to fix it today. -- Comment By: Simon Marlow (simonmar) Date: 2005-07-11 10:36 Message: Logged In: YES user_id=48280 ghci015 now tests for this bug. -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-05-23 12:57 Message: Logged In: YES user_id=50165 I'm bumping up the priority of this bug, because it also happens if, in GHCi, you say Prelude :m +Text.Show.Functions Text.Show.Functions print (\x - x) (this elicits a no-such-instance error) It's even more perplexing that this does not happen if you say print id becuase 'id' has kind-defaulted type variables in its type. Sigh. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=807249group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1231273 ] confusing error
Bugs item #1231273, was opened at 2005-07-01 22:01 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1231273group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Andrew Pimlott (pimlott) Assigned to: Simon Peyton Jones (simonpj) Summary: confusing error Initial Comment: I got a perplexing error message. Here is a concise example: t = ((\Just x - x) :: Maybe a - a) (Just 1) Try.hs:1:6: Couldn't match the rigid variable `a' against `t - t1' `a' is bound by the polymorphic type `forall a. Maybe a - a' at Try.hs:1:5-34 Expected type: a Inferred type: t - t1 In the expression: (\ Just x - x) :: Maybe a - a In the definition of `t': t = ((\ Just x - x) :: Maybe a - a) (Just 1) Failed, modules loaded: none. It seems to be telling me that the whole expression (Just x - x) :: Maybe a - a was expected to have type a, in contradiction to the explicit type annotation it prints out! In the context of a larger program, this threw me for a loop. I would have expected Expected type: Maybe - a Inferred type: Maybe - t - t1 Even better, if I change the code, I get a helpful diagnostic: t = (\Just x - x) (Just 1) Try.hs:1:6: Constructor `Just' should have 1 argument, but has been given 0 When checking the pattern: Just In a lambda abstraction: \ Just x - x In the definition of `t': t = (\ Just x - x) (Just 1) Failed, modules loaded: none. Could I get that error in the first example? You could probably go even further: (did you forget parentheses around the pattern?). -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-07-11 10:52 Message: Logged In: YES user_id=50165 Good bug report. I've improved the message a lot: tcfail140.hs:16:6: The lambda expression `\ Just x - ...' has two argumentss, but its type `Maybe a - a' has only one In the expression: (\ Just x - x) :: Maybe a - a In the definition of `t': t = ((\ Just x - x) :: Maybe a - a) (Just 1) test is tcfail140 Simon -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1231273group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1234458 ] Hardcoded path to perl.exe
Bugs item #1234458, was opened at 2005-07-07 22:18 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1234458group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Hardcoded path to perl.exe Initial Comment: I apologize in advance for not selecting a proper category but as I am an extreme neophyte - I didn't know what to select. I use GHC primarily to build Pugs (http://pugscode.org) I got frustrated that on Win32, the current working directory supercedes the %PATH variable and the perl.exe in the GHC root directory was getting used instead of my freshly installed 5.8.7 I deleted the file and corresponding perl56.dll and everything appeared to be working fine and yet Pugs would fail to build spitting out a cryptic 0x01 error (not exactly sure what the code was but it wasn't helpful). Since I had deleted the files instead of renaming them (hindsight always being 20/20) and not wanting to install GHC all over again just to see if for some strange reason that was the problem - I copied over the perl.exe and perl58.dll and what do you know - it worked. My bug report then is this - if there is some valid reason to hardcode a path to the GHC root directory for perl instead of looking in %PATH as a backup plan - then please make any error message more descriptive. Note: Not being very familiar with GHC, it might be that the error message was very informative and that it is the Pugs build process fault for not carrying it over. If that is the case then please disregard and please forgive. Cheers, Joshua Gatcomb a.k.a. Limbic~Region [EMAIL PROTECTED] -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-07-11 10:56 Message: Logged In: YES user_id=50165 Can you explain why this is a problem for you? We consider it a feature, not a bug, that GHC invokes its own private copy of perl when GHC runs its own private perl scripts (actually, I think the only perl script is the Evil Mangler). That way we aren't exposed to version skew in perl, nor do we require users to even have perl installed. Why does it cause a problem for you? Perhaps GHC's perl doesn't run on your box. But I wonder why not The only script it's being asked to run is the one that comes with GHC itself. Simon -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1234458group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [ 1213876 ] Xlib Types Not Instances of Anything
[EMAIL PROTECTED] wrote: The types defined by newtype in Graphics.X11.Xlib.Types are not instances of any type classes. Ptr, on the other hand, which these types are synonyms for, is an instance of Eq, Ord, Show, Typeable, Data, Storable, and several other classes not relevant to the usage of pointers in Graphics.X11.Xlib. Which instances do you want added? Sorry; I thought that was clear: Eq, Ord, Show, Typeable, Data, and Storable instances for Display, Screen, Visual, FontStruct, GC, XGCValues, and XSetWindowAttributes. Jon Cast ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Compiling ghc 6.4 with ghc 5.04.3
On 06 July 2005 10:50, Axel Simon wrote: On Wed, 2005-07-06 at 10:06 +0100, Simon Peyton-Jones wrote: That's weird. We compile 6.4 with 5.04.3 every night. Maybe you are using different flags than we are? - can you send your build.mk I haven't changed anything, i.e. no build.mk. - plus a full transcript so we can see what flags are being passed to ghc (e.g. -O2) below is the full last invocation of the link stage that fails (stage1 compiler), attached is that invocation redone with -v Is your source tree for 6.4 - the STABLE branch, or - the exact bits for 6.4 downloaded from the download site? It's the tar ball from the web-site. Under /lib there is libc-2.2.5.so and libc.so.6. Is there any other prerequisite that this Debian machine might not fulfil? I just built both a clean 6.4 tree and the current STABLE branch with the 5.04.3 we have installed here, no problems at all. It's probably a subtle bug in 5.04.3, but there's not much we can do without a way to reproduce, and since it's in an old version of GHC the value of tracking down the bug is reduced (it may or may not still be present). You can work around it by compiling stage1 without the native code generator: add GhcWithNativeCodeGen=NO to mk/build.mk, and then remove it before compiling stage 2. Other workarounds may work; eg. compiling AsmCodeGen without optimisation (you have to hack ghc/compiler/Makefile to do this). Or simply compile the whole of stage1 without optimisation: add GhcStage1HcOpts+=-Onot to mk/build.mk. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
make fail for 6.4.1-pre-July-11
It still cannot make. I have downloaded ghc-6.4.1-pre of CVS July 11 2005 (this is the date of the act of downloading) and am trying to make it with ghc-6.4.1-pre of June 15 under Debian Linux. It reports - ... ... /home/mechvel/ghc/cvs/instJune14/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/c\odeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -istage1/ghci -Istage1 -DGHCI -package template-haskell -package ... ... ... rename/RnExpr.lhs:85:4: Couldn't match `IOEnv (Env TcGblEnv TcLclEnv) (a, FreeVars)' against `t - \t1' Expected type: IOEnv (Env TcGblEnv TcLclEnv) (a, FreeVars) Inferred type: t - t1 Expected type: a1 - b Inferred type: RnM (a, FreeVars) Probable cause: `rnPatsAndThen' is applied to too many arguments in the call (rnPatsAndThen ctxt True pats) ghc: 76871052 bytes, 21 GCs, 4067284/8625320 avg/max bytes residency (4 sampl\es), 19M in use, 0.02 INIT (0.00 elapsed), 0.97 MUT (1.10 elapsed), 0.90 GC (0.\90 elapsed) :ghc make[2]: *** [stage1/rename/RnExpr.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/mechvel/ghc/cvs/pre6.4.1/fptools/ghc' make: *** [build] Error 1 --- ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1234458 ] Hardcoded path to perl.exe
Bugs item #1234458, was opened at 2005-07-07 15:18 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1234458group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 6.4 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Hardcoded path to perl.exe Initial Comment: I apologize in advance for not selecting a proper category but as I am an extreme neophyte - I didn't know what to select. I use GHC primarily to build Pugs (http://pugscode.org) I got frustrated that on Win32, the current working directory supercedes the %PATH variable and the perl.exe in the GHC root directory was getting used instead of my freshly installed 5.8.7 I deleted the file and corresponding perl56.dll and everything appeared to be working fine and yet Pugs would fail to build spitting out a cryptic 0x01 error (not exactly sure what the code was but it wasn't helpful). Since I had deleted the files instead of renaming them (hindsight always being 20/20) and not wanting to install GHC all over again just to see if for some strange reason that was the problem - I copied over the perl.exe and perl58.dll and what do you know - it worked. My bug report then is this - if there is some valid reason to hardcode a path to the GHC root directory for perl instead of looking in %PATH as a backup plan - then please make any error message more descriptive. Note: Not being very familiar with GHC, it might be that the error message was very informative and that it is the Pugs build process fault for not carrying it over. If that is the case then please disregard and please forgive. Cheers, Joshua Gatcomb a.k.a. Limbic~Region [EMAIL PROTECTED] -- Comment By: Nobody/Anonymous (nobody) Date: 2005-07-11 05:27 Message: Logged In: NO I need to apologize again. As a non-registered user, I suspect my reply will be posted under the root thread instead of simonpj It is a problem for a handful of reasons. 1. When I in the GHC root directory, that version takes precedence over any system installed perl. In addition to being a different version, it does not have access to all the modules installed in the system perl's @INC 2. The error message that the executable is missing in no way tells me that is what the problem is. As I indicated previously, it may be that the Pugs build process just wasn't passing on the information correctly - but I don't suspect this is the case. 3. I am not saying that GHC should not include its own copy of the perl executable for many of the same reasons you indicated. I am saying that it would be more user friendly if it looked in %PATH if it wasn't found in the hard coded path as backup. Alternatively, renaming it. As a command line biggot, this is primarily only a problem on Win32 as the current directory takes precedence over the PATH environment variable. Making this more user friendly can, in my neophyte opinion, be done without a negative impact to GHC's goals. Cheers, Joshua Gatcomb a.k.a. Limbic~Region [EMAIL PROTECTED] -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-07-11 03:56 Message: Logged In: YES user_id=50165 Can you explain why this is a problem for you? We consider it a feature, not a bug, that GHC invokes its own private copy of perl when GHC runs its own private perl scripts (actually, I think the only perl script is the Evil Mangler). That way we aren't exposed to version skew in perl, nor do we require users to even have perl installed. Why does it cause a problem for you? Perhaps GHC's perl doesn't run on your box. But I wonder why not The only script it's being asked to run is the one that comes with GHC itself. Simon -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1234458group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: make fail for 6.4.1-pre-July-11
I think you may have caught GHC just after a bogus change was merged. It was fixed a few minutes later. Try now. SImon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani | Sent: 11 July 2005 13:14 | To: glasgow-haskell-bugs@haskell.org | Subject: make fail for 6.4.1-pre-July-11 | | It still cannot make. | I have downloaded ghc-6.4.1-pre of CVS July 11 2005 | | (this is the date of the act of downloading) | | and am trying to make it with ghc-6.4.1-pre of June 15 | under Debian Linux. | It reports | | - | ... | ... | /home/mechvel/ghc/cvs/instJune14/bin/ghc -H16m -O -istage1/utils | -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude | -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn | -istage1/specialise -istage1/simplCore -istage1/stranal | -istage1/stgSyn -istage1/simplStg -istage1/c\odeGen -istage1/main | -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan | -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen | -istage1/ghci -Istage1 -DGHCI -package template-haskell -package ... | ... | ... | rename/RnExpr.lhs:85:4: | Couldn't match `IOEnv (Env TcGblEnv TcLclEnv) (a, FreeVars)' against | `t - \t1' | Expected type: IOEnv (Env TcGblEnv TcLclEnv) (a, FreeVars) | Inferred type: t - t1 | Expected type: a1 - b | Inferred type: RnM (a, FreeVars) | Probable cause: | `rnPatsAndThen' is applied to too many arguments in the call | (rnPatsAndThen ctxt True pats) | ghc: 76871052 bytes, 21 GCs, 4067284/8625320 avg/max bytes residency | (4 sampl\es), 19M in use, 0.02 INIT (0.00 elapsed), 0.97 MUT | (1.10 elapsed), 0.90 GC (0.\90 elapsed) :ghc | make[2]: *** [stage1/rename/RnExpr.o] Error 1 | make[1]: *** [all] Error 1 | make[1]: Leaving directory `/home/mechvel/ghc/cvs/pre6.4.1/fptools/ghc' | make: *** [build] Error 1 | --- | | | ___ | 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
