From trac at galois.com Wed Aug 1 05:58:11 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 05:50:31 2007 Subject: [GHC] #1572: Make it easy to find documentation for installed packages Message-ID: <071.557b7f4738cf91cc6c4a7972c295511b@localhost> #1572: Make it easy to find documentation for installed packages -----------------------+---------------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- `ghc-pkg` builds a package database that helps GHC find all installed packages. But it'd be a great improment if the same step also helped the '''user''' find the Haddock documentation for all installed packages. Corresponding to GHC's package database would be an HTML page that is a single point of entry for the user to find documentation about installed packages. Preferably together with a consolidated index. (And maybe `ghc --help` should give the local URL of this documentation root.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 08:57:46 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 08:50:06 2007 Subject: [GHC] #1571: type of synthesize in Data.Generics.Schemes is too restrictive In-Reply-To: <071.ac0072fe030d941deb5a7b41c64fac75@localhost> References: <071.ac0072fe030d941deb5a7b41c64fac75@localhost> Message-ID: <080.38523de22d205fd0ddc9dfdfb793d9fb@localhost> #1571: type of synthesize in Data.Generics.Schemes is too restrictive ------------------------------------+--------------------------------------- Reporter: sciolizer@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: synthesize,syb | Difficulty: Easy (1 hr) Os: Linux | Testcase: Architecture: x86 | ------------------------------------+--------------------------------------- Changes (by simonpj): * resolution: => fixed * status: new => closed Old description: > The type of the synthesize function in Data.Generics.Schemes is > unnecessarily restrictive. It's current type is > > synthesize :: s -> (s -> s -> s) -> GenericQ (s -> s) -> GenericQ s > > but it would be more useful if it were > > synthesize :: s -> (t -> s -> s) -> GenericQ (s -> t) -> GenericQ t > > Below is a contrived example demonstrating why one might want the more > liberal type. > > module Main where > > import Data.Generics > > synthesize' :: s -> (t -> s -> s) -> GenericQ (s -> t) -> GenericQ t > synthesize' z o f x = f x (foldr o z (gmapQ (synthesize' z o f) x)) > > -- The toTree function fails to type if synthesize' is replaced > -- with synthesize. > > data ConstructorTree = ConstructorTree String [ConstructorTree] deriving > (Show) > > toTree :: Data a => a -> ConstructorTree > toTree = synthesize' [] (:) (\a s -> ConstructorTree (showConstr > (toConstr a)) s) > > data Foo = Bar String | Baz Foo Int deriving (Data,Typeable) > > main = print (toTree (Baz (Bar "12") 5)) New description: The type of the synthesize function in Data.Generics.Schemes is unnecessarily restrictive. It's current type is {{{ synthesize :: s -> (s -> s -> s) -> GenericQ (s -> s) -> GenericQ s }}} but it would be more useful if it were {{{ synthesize :: s -> (t -> s -> s) -> GenericQ (s -> t) -> GenericQ t }}} Below is a contrived example demonstrating why one might want the more liberal type. {{{ module Main where import Data.Generics synthesize' :: s -> (t -> s -> s) -> GenericQ (s -> t) -> GenericQ t synthesize' z o f x = f x (foldr o z (gmapQ (synthesize' z o f) x)) -- The toTree function fails to type if synthesize' is replaced -- with synthesize. data ConstructorTree = ConstructorTree String [ConstructorTree] deriving (Show) toTree :: Data a => a -> ConstructorTree toTree = synthesize' [] (:) (\a s -> ConstructorTree (showConstr (toConstr a)) s) data Foo = Bar String | Baz Foo Int deriving (Data,Typeable) main = print (toTree (Baz (Bar "12") 5)) }}} Comment: Fair enough. `synthesize` does indeed have the more general type, so I've generalised it as you suggest. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 09:23:21 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 09:15:43 2007 Subject: [GHC] #1564: The fantastic Any type gets derived In-Reply-To: <071.6f122d83b8d94c6ac600f1d6a5c0f12f@localhost> References: <071.6f122d83b8d94c6ac600f1d6a5c0f12f@localhost> Message-ID: <080.483d12e5a5d5a2fd9760001868759e88@localhost> #1564: The fantastic Any type gets derived ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: closed Priority: highest | Milestone: Component: GHCi | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: tc235 Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by simonpj): * resolution: => fixed * testcase: => tc235 * status: new => closed Comment: Good bug, now fixed. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 09:44:31 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 09:36:52 2007 Subject: [GHC] #1542: Data/Time/Format/Parse cannot be compiled with -DDEBUG In-Reply-To: <071.2d2994b19013b8b90c069d69e1b5f941@localhost> References: <071.2d2994b19013b8b90c069d69e1b5f941@localhost> Message-ID: <080.d8da2b36d541dfdae29998ffe49710c9@localhost> #1542: Data/Time/Format/Parse cannot be compiled with -DDEBUG -----------------------------------------+---------------------------------- Reporter: Christian.Maeder@dfki.de | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonpj): * resolution: => wontfix * status: new => closed Comment: I've just tried this with the HEAD, and it's fine, so I'm inclined not to worry. If anyone sees this error with HEAD I'd certainly investigate though. So I'll make this "wontfix" for now. Thanks for reporting it though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 10:13:02 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 10:05:22 2007 Subject: [GHC] #1446: -fallow-incoherent-instances suggested when already used In-Reply-To: <071.effa73c05fff678d1d71b0c5d7423067@localhost> References: <071.effa73c05fff678d1d71b0c5d7423067@localhost> Message-ID: <080.2428ad51dcd8aeb6c5a7b3d32e84df88@localhost> #1446: -fallow-incoherent-instances suggested when already used ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by simonpj): * resolution: => invalid * status: new => closed Comment: The error message now says: {{{ To pick the first instance above, use -fallow-incoherent-instances when compiling the other instance declarations }}} I hope that makes it clear why the message appears even though `-fallow- incoherent-instances` is set for the module that is actually being compiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 10:22:07 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 10:14:28 2007 Subject: [GHC] #1526: -fobject-code is ignored for interactive compilation In-Reply-To: <071.159d2e28686c8badf9268b69d2898da2@localhost> References: <071.159d2e28686c8badf9268b69d2898da2@localhost> Message-ID: <080.8153b8a67ff4c5c63c8f935244317e4d@localhost> #1526: -fobject-code is ignored for interactive compilation -------------------------+-------------------------------------------------- Reporter: sorear | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by simonpj): The message is indeed misleading. Code typed in at the GHCi prompt is compiled on the fly to bytecode only, never to object code. (Compiling command-line code to object code is probably not worth it.) So the immediate problem is that the message suggests using `-fobject- code` etc even though that won't help when compiling a fragment written on the command line, rather than a module. Trouble is, the message comes by way of an exception (`unboxedTupleException`) from the bowels of the bytecode generator `ByteCodeGen.lhs`. I don't know what the easiest way to tidy this up is. Perhpas catch the exception somewhere that knows what is being compiled. Or pass the info about command-line vs module into the bytecode compiler. Tiresome, for sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 10:23:46 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 10:16:07 2007 Subject: [GHC] #1525: :browse shouldn't print single-constructor data definitions twice In-Reply-To: <071.06ea34673a78a5ae63f73fbbe61b0bd7@localhost> References: <071.06ea34673a78a5ae63f73fbbe61b0bd7@localhost> Message-ID: <080.78e2040c7407e6510a7b193c011dcb18@localhost> #1525: :browse shouldn't print single-constructor data definitions twice --------------------------------+------------------------------------------- Reporter: sorear | Owner: simonpj Type: feature request | Status: new Priority: high | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: minor | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Changes (by simonpj): * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 10:26:28 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 10:18:50 2007 Subject: [GHC] #1558: make the testsuite work with THREADS=2 In-Reply-To: <071.372a9828e6f1dfdd65965f87aa100f22@localhost> References: <071.372a9828e6f1dfdd65965f87aa100f22@localhost> Message-ID: <080.86e420f5e43323b928d2570ea3dd51c6@localhost> #1558: make the testsuite work with THREADS=2 ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Test Suite | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | ---------------------------+------------------------------------------------ Comment (by simonmar): Also, I get a number of framework failures when running with THREADS=2: {{{ OVERALL SUMMARY for test run started at Wed Aug 1 15:15:16 BST 2007 1829 total tests, which gave rise to 7144 test cases, of which 74 caused framework failures 5607 were skipped 1405 expected passes 55 expected failures 0 unexpected passes 3 unexpected failures Unexpected failures: cabal01(normal) mod144(normal) mod167(normal) }}} e.g. {{{ =====> getEnvironment01(normal) cd ../../../libraries/unix/tests && '/64playpen/simonmar/testing/compiler/stage2/ghc-inplace' -no-recomp -dcore-lint -dcmm-lint -Dx86_64_unknown_linux -o getEnvironment01 getEnvironment01.hs -package unix >getEnvironment01.comp.stderr 2>&1 Compile failed (status 6656) errors were: *** framework failure for getEnvironment01(normal) : Traceback (most recent call last): File "/home/simonmar/darcs-all/work/ghc- testing/testsuite/driver/testlib.py", line 428, in do_test result = apply(func, [name,way] + args) File "/home/simonmar/darcs-all/work/ghc- testing/testsuite/driver/testlib.py", line 586, in compile_and_run return compile_and_run__( name, way, extra_hc_opts, '' , '') File "/home/simonmar/darcs-all/work/ghc- testing/testsuite/driver/testlib.py", line 573, in compile_and_run__ result = simple_build( name, way, extra_hc_opts, 0, top_mod, 1 ) File "/home/simonmar/darcs-all/work/ghc- testing/testsuite/driver/testlib.py", line 635, in simple_build if_verbose(1,open(actual_stderr).read()) IOError: [Errno 2] No such file or directory: '../../../libraries/unix/tests/getEnvironment01.comp.stderr' }}} This could be a bug in Python, perhaps related to signals and spawning processes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 11:23:26 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 11:15:46 2007 Subject: [GHC] #1454: Confusing or bug: :t and :i don't return same type In-Reply-To: <071.83752fa4be4f0068af76b5997e7cc5c6@localhost> References: <071.83752fa4be4f0068af76b5997e7cc5c6@localhost> Message-ID: <080.7e6d64bf1efe0d3dff646813f6ddc68f@localhost> #1454: Confusing or bug: :t and :i don't return same type ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by iampure@gmail.com): * resolution: worksforme => * status: closed => reopened -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 12:56:00 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 12:48:19 2007 Subject: [GHC] #1573: GADT and typeclass funcional dependencies not working well together Message-ID: <071.eb5e386c76d9cba50ea371bf5cf80b3a@localhost> #1573: GADT and typeclass funcional dependencies not working well together ---------------------------------------+------------------------------------ Reporter: matthew.pocock@ncl.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: ia64 ---------------------------------------+------------------------------------ To use GADTs in anger, I keep needing to put them into homogeneous collections (set, list etc.) but to do this the typing parameter needs hiding. Later, when you operate on elements of the list, you need to pattern-match to recover the actual type of the element, and then chain on calls to that. This doesn't seem to work well in practice when the operation to run relies upon a fundep. {{{ data Zero data Suc a data ListWithLength a b where Nill :: ListWithLength a Zero Cons :: a -> ListWithLength a b -> ListWithLength a (Suc b) class Even a instance Even Zero instance (Even e) => Even (Suc (Suc e)) -- have to model this as a class class (Even b) => DoubleUp a b | a -> b where doubleUp :: ListWithLength x a -> ListWithLength x b instance DoubleUp Zero Zero where doubleUp Nill = Nill instance (DoubleUp e f) => DoubleUp (Suc e) (Suc (Suc f)) where doubleUp (Cons x xs) = Cons x (Cons x (doubleUp xs)) -- we want to stick a load of these into a list, so we must wrap them up somehow data AnyLWL a where AnyLWL :: ListWithLength a b -> AnyLWL a -- now, we would like to apply doubleUp to each element of the list duAny :: [AnyLWL a] -> [AnyLWL a] duAny = map duAny_ where duAny_ (AnyLWL n@Nill) = AnyLWL $ doubleUp n duAny_ (AnyLWL c@(Cons _ _)) = AnyLWL $ doubleUp c $ ghc --make -fglasgow-exts -fallow-undecidable-instances -o listWithLength ListWithLength.hs [1 of 1] Compiling Main ( ListWithLength.hs, ListWithLength.o ) ListWithLength.hs:34:21: Couldn't match expected type `b' (a rigid variable) against inferred type `Zero' `b' is bound by the pattern for `AnyLWL' at ListWithLength.hs:34:12-24 In the pattern: Nill In the pattern: AnyLWL (n@Nill) In the definition of `duAny_': duAny_ (AnyLWL (n@Nill)) = AnyLWL $ (doubleUp n) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 14:16:59 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 14:09:19 2007 Subject: [GHC] #1572: Make it easy to find documentation for installed packages In-Reply-To: <071.557b7f4738cf91cc6c4a7972c295511b@localhost> References: <071.557b7f4738cf91cc6c4a7972c295511b@localhost> Message-ID: <080.77fc62e40243c28dd2bdfa74ca0c2b4f@localhost> #1572: Make it easy to find documentation for installed packages -------------------------+-------------------------------------------------- Reporter: simonpj | 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 | -------------------------+-------------------------------------------------- Changes (by claus): * cc: => claus.reinke@talk21.com Comment: there are also other tools who'd like easy access to that information, on behalf of the user;-) for instance, one of my haskell mode plugins for vim uses haddock's index to figure out which haskell identifiers have documentation, and where to find it: [http://www.cs.kent.ac.uk/people/staff/cr3/toolbox/haskell/Vim/ haskell_doc.vim] one would like at least '''a central html table of contents plus a central index for the user, plus a more accessible format of the index for ide- like tools'''. currently, the toc and index contain all packages built together with ghc, but the information in the index isn't easily accessible for tools. preferably, added packages should integrate their toc and index with the central ones (or include the central ones into their own central toc and index, if they are a user-build). also, i have found that ghc-pkg reports where the docs *might* be, even if they aren't installed! perhaps there should be a separate documentation package associated with each binary package? this is also related to #1226 (finding ghc user_guide installed location). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 18:22:48 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 18:15:06 2007 Subject: [GHC] #1574: Broken link Message-ID: <071.6ae818b4b1b8e19a4eb91ce60b38a6f8@localhost> #1574: Broken link --------------------------------+------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- On http://www.haskell.org/ghc/dist/current/docs/ the link ../users_guide/index.html is broken. Suggested fix to make sure this never happens again: let a broken link analyser be part of the build bots. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 19:09:49 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 19:02:08 2007 Subject: [GHC] #1575: Arrow: No match in record selector Var.tcTyVarDetails Message-ID: <071.b65192ff8e80733ba41d671d5daa4bf0@localhost> #1575: Arrow: No match in record selector Var.tcTyVarDetails --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 --------------------------------+------------------------------------------- '''compile error''' {{{ ../../compiler/stage1/ghc-inplace -package-name arrows-0.2.1 -hide-all- packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -package base-2.1 -O -O -fglasgow-exts -fallow-undecidable-instances -idist/build -H16m -O -O -Rghc-timing -fgenerics -c Control/Arrow/Transformer/Automaton.hs -o dist/build/Control/Arrow/Transformer/Automaton.o -ohi dist/build/Control/Arrow/Transformer/Automaton.hi ghc-6.7.20070801: panic! (the 'impossible' happened) (GHC version 6.7.20070801 for i386-unknown-linux): No match in record selector Var.tcTyVarDetails Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> make[2]: *** [dist/build/Control/Arrow/Transformer/Automaton.o] Error 1 make[2]: Leaving directory `/home/david/repos/ghc/libraries/arrows' make[1]: *** [make.library.arrows] Error 2 make[1]: Leaving directory `/home/david/repos/ghc/libraries' make: *** [stage1] Error 2 }}} '''uname -a''' {{{ Linux wrath 2.6.21-2-686 #1 SMP Wed Jul 11 03:53:02 UTC 2007 i686 GNU/Linux }}} '''gcc -v''' {{{ Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable- languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable- shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include- dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with- tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.3 20070629 (prerelease) (Debian 4.1.2-13) }}} '''ghc --version''' {{{ The Glorious Glasgow Haskell Compilation System, version 6.7.20070731 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 19:30:32 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 19:22:51 2007 Subject: [GHC] #631: GHCi doesn't work unregisterised In-Reply-To: <071.3d87a7df21d9c2bf083df338cb20a739@localhost> References: <071.3d87a7df21d9c2bf083df338cb20a739@localhost> Message-ID: <080.00b43265bf086c788b36fbbe312d22c9@localhost> #631: GHCi doesn't work unregisterised ------------------------------------+--------------------------------------- Reporter: trentbuck@gmail.com | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.4.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | ------------------------------------+--------------------------------------- Changes (by Isaac Dupree): * cc: => id@isaac.cedarswampstudios.org Comment: A number of things rely on ghci (some humans, runghc(runhaskell)...) and it would be nice to have those reliably working even on the architectures where it often isn't (or can't be?) built registerised at any given moment. (Debian would still have to change its packaging to not disable GHCI on the architectures where it chooses to build unregisterised, once this works...) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 19:42:24 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 19:34:43 2007 Subject: [GHC] #631: GHCi doesn't work unregisterised In-Reply-To: <071.3d87a7df21d9c2bf083df338cb20a739@localhost> References: <071.3d87a7df21d9c2bf083df338cb20a739@localhost> Message-ID: <080.a25e87551cc7d6446e781576d3af8a72@localhost> #631: GHCi doesn't work unregisterised ------------------------------------+--------------------------------------- Reporter: trentbuck@gmail.com | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.4.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | ------------------------------------+--------------------------------------- Changes (by duncan): * cc: id@isaac.cedarswampstudios.org => id@isaac.cedarswampstudios.org haskell@gentoo.org -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 19:52:23 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 19:44:42 2007 Subject: [GHC] #1576: Document Template Haskell API Message-ID: <071.fe24cb222d8cc4e4e9833aed813e408c@localhost> #1576: Document Template Haskell API --------------------------------+------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- Make Haddock documentation for Template Haskell API complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 20:14:33 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 20:06:51 2007 Subject: [GHC] #1526: -fobject-code is ignored for interactive compilation In-Reply-To: <071.159d2e28686c8badf9268b69d2898da2@localhost> References: <071.159d2e28686c8badf9268b69d2898da2@localhost> Message-ID: <080.8e60d049da56889ee3c8a80a471f2eb0@localhost> #1526: -fobject-code is ignored for interactive compilation -------------------------+-------------------------------------------------- Reporter: sorear | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by Isaac Dupree): * cc: => id@isaac.cedarswampstudios.org Comment: "(Compiling command-line code to object code is probably not worth it.)" a. When it is the only possible way to use unboxed tuples interactively, etc. b. Sometimes I want the convenience of a REPL when testing expressions that have quite large running time and it's a nuisance to put them in a file and compile (possibly with optimizations), repeatedly, just to make them run fast enough. So I think the possibility to do so is worth it as a user, assuming it isn't too difficult to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 1 20:18:20 2007 From: trac at galois.com (GHC) Date: Wed Aug 1 20:10:39 2007 Subject: [GHC] #1577: Give TH the ability to get the info for a class name Message-ID: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> #1577: Give TH the ability to get the info for a class name --------------------------------+------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- In a module M, where a class G is imported from a module N, I want to get all the methods and arities of G into some Info data structure. I thought Template Haskell already offered this possibility, but sorear claimed with very high confidence that this is not the case. In general: as much information as is available to the compiler should be exposed in the Q monad upto some sane cutoff. I think Template Haskell is not being used that much, because it has lots of arbitrary limitations and is not documented perfectly in one place. It's a vicious circle: because TH (although it costed lots of implementation effort already) is not perfect, there are little users. Because there are not many users, the implementation isn't perfect. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 03:41:13 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 03:33:30 2007 Subject: [GHC] #1577: Give TH the ability to get the info for a class name In-Reply-To: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> References: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> Message-ID: <080.12bc18c8a6499b24199f655a034c2c4c@localhost> #1577: Give TH the ability to get the info for a class name ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by simonpj): Well if you reify a class `Name` you get a `ClassI Dec` (see `Language.Haskell.TH.Syntax`). The `Dec` gives the class signature, and you can then reify the `Names` you find inside. So I'm not sure just what you want that isn't provided. I agree that it's possible that more features in TH would lead to more users, but it's hard to tell just ''which'' features! There is a lot that ''could'' be done. It'd be a great project for someone to take on. Meanwhile I'll try to (continue to) respond to concrete suggestions. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 03:47:36 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 03:39:54 2007 Subject: [GHC] #345: GADT - fundep interaction In-Reply-To: <071.bfc72a05ca553409f36f771922e06c54@localhost> References: <071.bfc72a05ca553409f36f771922e06c54@localhost> Message-ID: <080.00eef8392509055ec4d18934f8c8a3fc@localhost> #345: GADT - fundep interaction ----------------------------------------+----------------------------------- Reporter: bring | Owner: simonpj Type: bug | Status: assigned Priority: high | Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.4 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Os: Unknown | Testcase: gadt-fd Architecture: Unknown | ----------------------------------------+----------------------------------- Comment (by simonpj): See also #1573, which gives another example. I plan to fix this by the upcoming work on indexed type families. Tom Schrivjers has built a prototype implementation, which mostly works. I need to review and commit it. Stay tuned. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 03:48:14 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 03:40:30 2007 Subject: [GHC] #1573: GADT and typeclass funcional dependencies not working well together In-Reply-To: <071.eb5e386c76d9cba50ea371bf5cf80b3a@localhost> References: <071.eb5e386c76d9cba50ea371bf5cf80b3a@localhost> Message-ID: <080.a5719b7d5e8979d32a0e466c65353f06@localhost> #1573: GADT and typeclass funcional dependencies not working well together -----------------------------------------+---------------------------------- Reporter: matthew.pocock@ncl.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: ia64 | -----------------------------------------+---------------------------------- Comment (by simonpj): This is a dup of #345, so I'll close it. But #345 is high on my list, don't worry! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 03:48:21 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 03:40:38 2007 Subject: [GHC] #1573: GADT and typeclass funcional dependencies not working well together In-Reply-To: <071.eb5e386c76d9cba50ea371bf5cf80b3a@localhost> References: <071.eb5e386c76d9cba50ea371bf5cf80b3a@localhost> Message-ID: <080.2929aff15460cb8bf9218828f5405f7f@localhost> #1573: GADT and typeclass funcional dependencies not working well together -----------------------------------------+---------------------------------- Reporter: matthew.pocock@ncl.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: ia64 | -----------------------------------------+---------------------------------- Changes (by simonpj): * resolution: => duplicate * status: new => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 04:53:02 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 04:45:20 2007 Subject: [GHC] #1575: Arrow: No match in record selector Var.tcTyVarDetails In-Reply-To: <071.b65192ff8e80733ba41d671d5daa4bf0@localhost> References: <071.b65192ff8e80733ba41d671d5daa4bf0@localhost> Message-ID: <080.0be3b6ea9b54afc2a41051b0890ed62d@localhost> #1575: Arrow: No match in record selector Var.tcTyVarDetails ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonpj): * resolution: => fixed * status: new => closed Comment: Ooops sorry. Fixed; will commit when I've run 'validate'. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 06:24:49 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 06:17:09 2007 Subject: [GHC] #1577: Give TH the ability to get the info for a class name In-Reply-To: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> References: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> Message-ID: <080.c43c8da7de15f50107c2ba0d84d5af6e@localhost> #1577: Give TH the ability to get the info for a class name ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by iampure@gmail.com): In the following code with Foo a class name(i.e. class Foo x y zwhere...) that is is imported from another module: {{{a = $(do info <- reify (Name (mkOccName "Foo") NameS) () <- trace (show info) (return ()) (liftM (LitE . StringL) currentModule))}}} The problem is that whatever I try, I don't get an info value. I basically guessed the NameS constructor, since I don't know what the "S" stands for. So, the problem is getting access to the Info value. I am either reifying the wrong thing or this feature simply does not work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 06:26:16 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 06:18:33 2007 Subject: [GHC] #1577: Give TH the ability to get the info for a class name In-Reply-To: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> References: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> Message-ID: <080.f76393506d0e51c0dc3776f77b7027e9@localhost> #1577: Give TH the ability to get the info for a class name ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by simonpj): Try {{{ reify 'Foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 06:37:43 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 06:30:00 2007 Subject: [GHC] #1577: Give TH the ability to get the info for a class name In-Reply-To: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> References: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> Message-ID: <080.1e85672c451d662a8155b4c80d7e729f@localhost> #1577: Give TH the ability to get the info for a class name ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by iampure@gmail.com): Shouldn't the following work too then with Control.Monad loaded? {{{ a = reify 'Monad }}} I get: Not in scope: data constructor `Monad' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 06:47:04 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 06:39:21 2007 Subject: [GHC] #1578: darcs-all work around for darcs Issue 467 Message-ID: <071.5add40e79f778aa447b367399811aebb@localhost> #1578: darcs-all work around for darcs Issue 467 ---------------------------+------------------------------------------------ Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ---------------------------+------------------------------------------------ The darcs "Issue467: darcs changes --context interferes with --repodir" (http://bugs.darcs.net/issue467) causes this failure: {{{ $ perl darcs-all changes --context == running darcs changes --context Context: [FIX #1177, partially at least. ... [TAG 2007-06-12 Ian Lynagh **20070612213440] == running darcs changes --context --repodir nofib darcs failed: Not a repository: nofib (nofib/_darcs/inventory: openBinaryFile: does not exist (No such file or directory)) darcs failed: 512 at darcs-all line 57. }}} David Roundy found that "When given an absolute path, --context and --repodir work together fine." Here is a patch to darcs-all that uses this work around to repair {{{perl darcs-all changes --context}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 07:02:55 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 06:55:12 2007 Subject: [GHC] #1577: Give TH the ability to get the info for a class name In-Reply-To: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> References: <071.505bd1383f9cf9f83d85a0e0b397d5c4@localhost> Message-ID: <080.2ad4b02f075e6e8c035f06068230fbf3@localhost> #1577: Give TH the ability to get the info for a class name ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by simonpj): Sorry, you want {{{ reify ''Monad }}} This is described in 4.3 of `notes2.ps` pointed to from http://www.haskell.org/ghc/docs/latest/html/users_guide/template- haskell.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 07:11:36 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 07:03:54 2007 Subject: [GHC] #1578: darcs-all work around for darcs Issue 467 In-Reply-To: <071.5add40e79f778aa447b367399811aebb@localhost> References: <071.5add40e79f778aa447b367399811aebb@localhost> Message-ID: <080.14a47280a20797d9f0a9791426823046@localhost> #1578: darcs-all work around for darcs Issue 467 -----------------------------+---------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Comment (by thorkilnaur): And remember that pulling darcs-all changes with darcs-all was dangerous at some point and perhaps still is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 07:14:51 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 07:07:07 2007 Subject: [GHC] #1525: :browse shouldn't print single-constructor data definitions twice In-Reply-To: <071.06ea34673a78a5ae63f73fbbe61b0bd7@localhost> References: <071.06ea34673a78a5ae63f73fbbe61b0bd7@localhost> Message-ID: <080.2989d397831a9c6e3b326bc5453416ff@localhost> #1525: :browse shouldn't print single-constructor data definitions twice --------------------------------+------------------------------------------- Reporter: sorear | Owner: simonpj Type: feature request | Status: closed Priority: high | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: ghci011 Architecture: Unknown | --------------------------------+------------------------------------------- Changes (by simonpj): * resolution: => fixed * testcase: => ghci011 * status: new => closed Comment: Fixed. There was a lurking "ToDo" in `InteractiveUI`. A reasonable test is ghci011 (whose output had been incorrectly updated). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 11:40:55 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 11:33:11 2007 Subject: [GHC] #1579: instance Read Integer contradicts Haskell98 Message-ID: <071.e0ad3c6915a798ab194b67129f9323b3@localhost> #1579: instance Read Integer contradicts Haskell98 -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | 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/onlinereport/standard-prelude.html says {{{ instance Read Integer where readsPrec p = readSigned readDec }}} However, I get contradictory results in GHCi: {{{ Prelude Numeric> readsPrec undefined "-(21602)zzz" :: [(Integer,String)] [(-21602,"zzz")] Prelude Numeric> readSigned readDec "-(21602)zzz" :: [(Integer,String)] [] }}} (hugs, however, gives `[]` for both results) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 11:44:17 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 11:36:33 2007 Subject: [GHC] #1579: instance Read Integer contradicts Haskell98 In-Reply-To: <071.e0ad3c6915a798ab194b67129f9323b3@localhost> References: <071.e0ad3c6915a798ab194b67129f9323b3@localhost> Message-ID: <080.3ad1e431ece9793c62ef31fd914ab782@localhost> #1579: instance Read Integer contradicts Haskell98 -------------------------------+-------------------------------------------- Reporter: Isaac Dupree | 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 Isaac Dupree): (I initially discovered this while QuickCheck-ing an Integer replacement that defines `instance Read MyInteger where readsPrec _ = readSigned readDec`, against GHC's built-in Integer, and got an inconsistent result.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 13:11:58 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 13:04:16 2007 Subject: [GHC] #1580: Get GHC happy with alternate base packages (split base) Message-ID: <071.37988d4c6550c6ac98720a34f883b568@localhost> #1580: Get GHC happy with alternate base packages (split base) -----------------------+---------------------------------------------------- Reporter: SamB | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- There are a ''lot'' of things wired into the compiler that would make it hard to create an alternate base package. See BaseSplit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 20:35:29 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 20:27:45 2007 Subject: [GHC] #1581: :info doesn't show all instances Message-ID: <071.45f4f02fb7f4c53771e3934efa17b312@localhost> #1581: :info doesn't show all instances --------------------------------+------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- Doing :info doesn't show the instance in the module containing an instance in the test case. This happened in real code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 22:25:10 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 22:17:25 2007 Subject: [GHC] #1582: impossible: TODO: gc_target Message-ID: <071.d94b1e4bd879b584c1fa06fc7b1fe0d8@localhost> #1582: impossible: TODO: gc_target -----------------------+---------------------------------------------------- Reporter: sorear | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 -----------------------+---------------------------------------------------- {{{ stefan@stefans:/tmp$ cat Y.hs module Y(a,b) where a = a b ::Bool b = b stefan@stefans:/tmp$ ghc -fforce-recomp -c Y.hs #note lack of crash stefan@stefans:/tmp$ ghc -ddump-cmm -c Y.hs #note lack of crash ==================== Cmm ==================== section "relreadonly" { Y_b_srt: const Y_b_closure; } section "data" { Y_b_closure: const Y_b_info; const 0; const 0; const 0; } Y_b_entry() {ghc-6.7.20070712: panic! (the 'impossible' happened) (GHC version 6.7.20070712 for i386-unknown-linux): TODO: gc_target Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug stefan@stefans:/tmp$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 2 22:26:28 2007 From: trac at galois.com (GHC) Date: Thu Aug 2 22:18:43 2007 Subject: [GHC] #1582: impossible: TODO: gc_target In-Reply-To: <071.d94b1e4bd879b584c1fa06fc7b1fe0d8@localhost> References: <071.d94b1e4bd879b584c1fa06fc7b1fe0d8@localhost> Message-ID: <080.636b88fd5f6bd5a90fb59aefbe9d6351@localhost> #1582: impossible: TODO: gc_target -------------------------+-------------------------------------------------- Reporter: sorear | 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 sorear): The second '#note lack of crash' was a simple line editing error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 3 05:39:13 2007 From: trac at galois.com (GHC) Date: Fri Aug 3 05:31:27 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.7942790263d458cb1a769476a8b38fc6@localhost> #1372: Recompilation checker should consider package versions (and other factors) -------------------------+-------------------------------------------------- Reporter: bringert | Owner: simonmar 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 | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm looking at this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 3 06:56:05 2007 From: trac at galois.com (GHC) Date: Fri Aug 3 06:48:20 2007 Subject: [GHC] #1583: GHCi + large Integer arithmetic + Ctrl-C = bad Message-ID: <071.9aefc244abc1313c4b1fa45781cca02e@localhost> #1583: GHCi + large Integer arithmetic + Ctrl-C = bad ---------------------------+------------------------------------------------ Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Multiple ---------------------------+------------------------------------------------ Now detected and mostly repeatable on x86, not just powerpc. {{{ $ ghci Prelude> product [1..50000] [press control-C repeatedly, without pausing the assault, until the following line appears:] 3347320509: exception :: GhcException [sometimes this line appears instead, in which case try again until GhcException reproduced: 3347320509Interrupted.] }}} The exact number of digits printed can vary - they ARE the initial digits of 50000! (factorial), by the way. The `GhcException` can happen whether this expression is the first thing to be entered into the ghci prompt session or not. Once it happens, the terminal is rather frozen, although control-Z to suspend ghci and regain a shell prompt, seems to make the terminal usable again, and `kill (ghc's pid)` or `kill -9 (ghc's pid)` (I needed the -9/-KILL once and not another time I tried, inexplicably) also returns from ghci to my shell. Even when not so many control-C's are used and it just says Interrupted, ghci takes an awfully long time before returning to the ghci prompt, which is undesirable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 3 06:56:27 2007 From: trac at galois.com (GHC) Date: Fri Aug 3 06:48:41 2007 Subject: [GHC] #1582: impossible: TODO: gc_target In-Reply-To: <071.d94b1e4bd879b584c1fa06fc7b1fe0d8@localhost> References: <071.d94b1e4bd879b584c1fa06fc7b1fe0d8@localhost> Message-ID: <080.e0164df620f3fa6f21b1ab0da5b24685@localhost> #1582: impossible: TODO: gc_target -------------------------+-------------------------------------------------- Reporter: sorear | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: crashing code temporarily commented out, this is work in progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 3 10:50:26 2007 From: trac at galois.com (GHC) Date: Fri Aug 3 10:42:40 2007 Subject: [GHC] #1584: problem presenting with explicit pattern matching Message-ID: <071.b310bd48623437f14cbd53de66531989@localhost> #1584: problem presenting with explicit pattern matching -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 -----------------------+---------------------------------------------------- Hi all, I believe I've found a bug in ghc 6.6.1. From Chapter 9. What to do when something goes wrong ?I think GHC is producing incorrect code?: Unlikely :-) And yet I'm out of ideas on why my code is acting the way it does. I've got a tiny program for the towers of hanoi. In my step function moving one disk to the next peg I seem to be hitting a bug for explicit pattern matching. I have a small example file (included below) to detail the issue. 1. What kind of machine am I running on? {{{ $ uname -a Linux lanny-lnx 2.4.21-32.0.1.EL #1 Tue May 17 18:01:37 EDT 2005 i686 i686 i386 GNU/Linux }}} I have also reproduced the bug (using ghc 6.6.1) on a Mac OS X system. My linux box uses the rpm install from haskell.org/ghc but on the mac I built ghc from the ground up (via http://darwinports.com). 2. What version of gcc am I using? {{{ $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386- redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52) }}} The mac is using the latest Xcode so it's got gcc 4.0.x 3. Complete ghci -v run showing problem. {{{ $ ghci -v hanoi_bug.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Using package config file: /opt/ghc-6.6.1/lib/i386-unknown- linux/package.conf wired-in package base mapped to base-2.1.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-2.1 Hsc static flags: -static Loading package base ... linking ... done. wired-in package base mapped to base-2.1.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-2.1 *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: wired-in package base mapped to base-2.1.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-2.1 *** Chasing dependencies: Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Upsweep completely successful. *** Deleting temp files: Deleting: *** Chasing dependencies: Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] compile: input file hanoi_bug.hs *** Checking old interface for main:Main: [1 of 1] Compiling Main ( hanoi_bug.hs, interpreted ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 1076 *** Simplify: Result size = 1523 Result size = 1323 Result size = 1323 *** Tidy Core: Result size = 1323 *** CorePrep: Result size = 1641 *** ByteCodeGen: *** Deleting temp files: Deleting: Upsweep completely successful. *** Deleting temp files: Deleting: Ok, modules loaded: Main. *Main> main *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: [True,True,True,False,False,True] *Main> :q Leaving GHCi. *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: }}} 5. What program behavior is wrong? main is recording a list of properties which should all return True. The behavior is the same for compiled rather than interpreted code on both the linux and mac systems. 6. Source code demonstrating the problem. {{{ $ cat hanoi_bug.hs -- A Task is a tuple of -- n :: The number of disks to move -- i :: The initial peg -- a :: The auxillary peg -- f :: The final peg type Task = (Int, Int, Int, Int) data Tower a = Tower a a a deriving (Eq, Show) peg :: Int -> Tower [a] -> [a] peg 1 (Tower a b c) = a peg 2 (Tower a b c) = b peg 3 (Tower a b c) = c mkTower :: Task -> [a] -> [a] -> [a] -> Tower [a] mkTower (_,1,2,3) a b c = Tower a b c mkTower (_,1,3,2) a b c = Tower a c b mkTower (_,2,1,3) a b c = Tower b a c mkTower (_,2,3,1) a b c = Tower b c a -- BUG! returns (Tower c a b) mkTower (_,3,1,2) a b c = Tower c a b -- BUG! returns (Tower b c a) mkTower (_,3,2,1) a b c = Tower c b a step :: Task -> Tower [a] -> Tower [a] step task@(_,i,a,f) tower = let pi = peg i tower pa = peg a tower pf = peg f tower in mkTower task (tail pi) pa (head pi : pf) prop_test123 = step (1,1,2,3) (Tower [1] [3] [2]) == Tower [] [3] [1,2] prop_test132 = step (1,1,3,2) (Tower [1] [2] [3]) == Tower [] [1,2] [3] prop_test213 = step (1,2,1,3) (Tower [3] [1] [2]) == Tower [3] [] [1,2] prop_test231 = step (1,2,3,1) (Tower [2] [1] [3]) == Tower [1,2] [] [3] prop_test312 = step (1,3,1,2) (Tower [3] [2] [1]) == Tower [3] [1,2] [] prop_test321 = step (1,3,2,1) (Tower [2] [3] [1]) == Tower [1,2] [3] [] checkProps = [ prop_test123 , prop_test132 , prop_test213 , prop_test231 , prop_test312 , prop_test321 ] main :: IO () main = print checkProps }}} 7. If you are a hero... Sorry. Not yet. At a guess the book-keeping for explicit pattern matches is getting mixed up. Note that mkTower does provide the correct permutations, it's just that two of them are mixed up. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 01:27:04 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 01:19:16 2007 Subject: [GHC] #1585: Um, an error, I don't even understand it. Message-ID: <071.c92cba46d61d57860a51bbdaac12e6b5@localhost> #1585: Um, an error, I don't even understand it. -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 -----------------------+---------------------------------------------------- this is the output of a ghc error I found, it wanted me to tell you about it, so... Here is my xmonad dir: http://www.timthelion.com/xmonad.tar {{{ /home/timothy/s/b/xmonad$runhaskell Setup.lhs build timothy 22:05 timsecat pts/5 Preprocessing executables for xmonad-0.2... Building xmonad-0.2... [ 5 of 10] Compiling Config[boot] ( Config.hs-boot, nothing ) [ 7 of 10] Compiling XMonadContrib.Roledex ( XMonadContrib/Roledex.hs, dist/build/xmonad/xmonad-tmp/XMonadContrib/Roledex.o ) ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for i386-unknown-linux): checkKind: adding kind constraint t{tv a2S0} [tv] * t_a2Jt{tv} [tau] t_a2Jt{tv} [tau] ?? Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug You have new mail. /home/timothy/s/b/xmonad$runhaskell Setup.lhs clean timothy 22:05 timsecat pts/5 cleaning... /home/timothy/s/b/xmonad$runhaskell Setup.lhs build timothy 22:06 timsecat pts/5 Setup.lhs: error reading ./.setup-config; run "setup configure" command? /home/timothy/s/b/xmonad$runhaskell Setup.lhs configure --prefix /home/timothy/bin timothy 22:06 timsecat pts/5 Configuring xmonad-0.2... configure: /usr/bin/ghc-pkg configure: Dependency base>=2.0: using base-2.0 configure: Dependency X11>=1.2.1: using X11-1.2.2 configure: Dependency X11-extras>=0.2: using X11-extras-0.2 configure: Dependency mtl>=1.0: using mtl-1.0 configure: Dependency unix>=1.0: using unix-1.0 configure: Using install prefix: /home/timothy/bin configure: Binaries installed in: /home/timothy/bin/bin configure: Libraries installed in: /home/timothy/bin/lib/xmonad-0.2/ghc-6.6 configure: Private binaries installed in: /home/timothy/bin/libexec configure: Data files installed in: /home/timothy/bin/share/xmonad-0.2 configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.6 configure: Using package tool: /usr/bin/ghc-pkg configure: Using ar found on system at: /usr/bin/ar configure: Using haddock found on system at: /usr/bin/haddock configure: No pfesetup found configure: Using ranlib found on system at: /usr/bin/ranlib configure: Using runghc found on system at: /usr/bin/runghc configure: Using runhugs found on system at: /usr/bin/runhugs configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: Using c2hs: /usr/bin/c2hs configure: Using cpphs: /usr/bin/cpphs configure: No greencard found /home/timothy/s/b/xmonad$runhaskell Setup.lhs build timothy 22:07 timsecat pts/5 Preprocessing executables for xmonad-0.2... Building xmonad-0.2... [ 1 of 10] Compiling StackSet ( StackSet.hs, dist/build/xmonad /xmonad-tmp/StackSet.o ) [ 2 of 10] Compiling XMonad ( XMonad.hs, dist/build/xmonad /xmonad-tmp/XMonad.o ) [ 3 of 10] Compiling XMonadContrib.LayoutHelpers ( XMonadContrib/LayoutHelpers.hs, dist/build/xmonad/xmonad- tmp/XMonadContrib/LayoutHelpers.o ) [ 4 of 10] Compiling XMonadContrib.MagicFocus ( XMonadContrib/MagicFocus.hs, dist/build/xmonad/xmonad- tmp/XMonadContrib/MagicFocus.o ) [ 5 of 10] Compiling Config[boot] ( Config.hs-boot, nothing ) [ 6 of 10] Compiling Operations ( Operations.hs, dist/build/xmonad /xmonad-tmp/Operations.o ) [ 7 of 10] Compiling XMonadContrib.Roledex ( XMonadContrib/Roledex.hs, dist/build/xmonad/xmonad-tmp/XMonadContrib/Roledex.o ) ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for i386-unknown-linux): checkKind: adding kind constraint t{tv atT3} [tv] * t_atPI{tv} [tau] t_atPI{tv} [tau] ?? Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /home/timothy/s/b/xmonad$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 08:45:09 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 08:37:20 2007 Subject: [GHC] #1584: problem presenting with explicit pattern matching In-Reply-To: <071.b310bd48623437f14cbd53de66531989@localhost> References: <071.b310bd48623437f14cbd53de66531989@localhost> Message-ID: <080.ec252fd21e70a7bf570af02934ccf3f0@localhost> #1584: problem presenting with explicit pattern matching -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * resolution: => invalid * status: new => closed Comment: Thanks for the detailed report! However, hugs also disagrees with you, as does my by-hand evaluation: {{{ prop_test231 = step (1,2,3,1) (Tower [2] [1] [3]) = let pi = peg 2 (Tower [2] [1] [3]) pa = peg 3 (Tower [2] [1] [3]) pf = peg 1 (Tower [2] [1] [3]) in mkTower (1,2,3,1) (tail pi) pa (head pi : pf) = let pi = [1] pa = [3] pf = [2] in mkTower (1,2,3,1) (tail pi) pa (head pi : pf) = mkTower (1,2,3,1) [] [3] [1,2] = Tower [3] [1,2] [] != Tower [1,2] [] [3] }}} Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 09:00:22 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 08:52:32 2007 Subject: [GHC] #1585: Um, an error, I don't even understand it. In-Reply-To: <071.c92cba46d61d57860a51bbdaac12e6b5@localhost> References: <071.c92cba46d61d57860a51bbdaac12e6b5@localhost> Message-ID: <080.c5d6b958079fcfb09e2aabfb9a2a40ed@localhost> #1585: Um, an error, I don't even understand it. -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: 6.6.1 gives a proper error message: {{{ [...] [ 7 of 10] Compiling XMonadContrib.Roledex ( XMonadContrib/Roledex.hs, dist/buil d/xmonad/xmonad-tmp/XMonadContrib/Roledex.o ) XMonadContrib/Roledex.hs:42:43: Couldn't match expected type `Integer' against inferred type `Int' In the second argument of `(%)', namely `c' In the first argument of `splitHorizontallyBy', namely `(1 % c)' In the first argument of `($)', namely `splitHorizontallyBy (1 % c)' XMonadContrib/Roledex.hs:51:24: Couldn't match expected type `Position' against inferred type `Dimension' In the first argument of `mrect', namely `gw' In the expression: mrect gw gh rect In the definition of `mainPane': mainPane = mrect gw gh rect XMonadContrib/Roledex.hs:55:20: Couldn't match expected type `Position' against inferred type `Dimension' In the first argument of `mrect', namely `(gw * n)' In the expression: mrect (gw * n) (gh * n) rect In the definition of `f': f n = mrect (gw * n) (gh * n) rect }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 12:22:43 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 12:14:53 2007 Subject: [GHC] #1586: trace output ordering in HEAD incorrectly Message-ID: <071.4112f64953d4f857c8564af2c7d5bffc@localhost> #1586: trace output ordering in HEAD incorrectly --------------------------------+------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- I don't have a test case, but it appears that the Debug.Trace.trace output is ordered incorrectly. By incorrectly, I mean that it does not follow evaluation order. I suspect it will come up in every non-trivial use of it. In GHC-6.6.1 the output order was correct (modulo that the size of output was not equal during runs (but there is another report for that already)). In a program I have {{{ runFoo $ do () <- trace "hi" (return ()) () <- trace "there" (return ()) return () }}} prints: {{{ there hi }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 12:40:07 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 12:32:16 2007 Subject: [GHC] #1586: trace output ordering in HEAD incorrectly In-Reply-To: <071.4112f64953d4f857c8564af2c7d5bffc@localhost> References: <071.4112f64953d4f857c8564af2c7d5bffc@localhost> Message-ID: <080.3e9fdd4e7ff26bda662627dfd3eef0a7@localhost> #1586: trace output ordering in HEAD incorrectly ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by neil): {{{ main = do () <- trace "hi" (return ()) () <- trace "there" (return ()) return () :: IO () }}} This works fine for me in GHC 6.6.1, and HEAD from about 2 weeks ago. Are you sure that the monad you are in is IO? Can you give a complete program, including main. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 13:27:32 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 13:19:42 2007 Subject: [GHC] #1586: trace output ordering in HEAD incorrectly In-Reply-To: <071.4112f64953d4f857c8564af2c7d5bffc@localhost> References: <071.4112f64953d4f857c8564af2c7d5bffc@localhost> Message-ID: <080.ed5b0cd38b59101b392f1e62e09d4201@localhost> #1586: trace output ordering in HEAD incorrectly ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by iampure@gmail.com): Me: "I don't have a test case" Neil: "Can you give a complete program, including main." I am sorry, wasn't I clear enough? Neil: "Are you sure that the monad you are in is IO?"? Huh, when did I say "IO"? If the test case would have been that easy, I'd have said: "I have a test case and this is it." (Of course I tried the above code in another monad(State (in my case)).) I am sure it's wrong. Creating test cases is not always trivial. I have the impression that this system is also for reporting "observations" about the system. These "observations" might later be confirmed by other people (or by me) with a real test case or a compiler writer might think "Oh, I changed something last week", etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 13:56:12 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 13:48:21 2007 Subject: [GHC] #1584: problem presenting with explicit pattern matching In-Reply-To: <071.b310bd48623437f14cbd53de66531989@localhost> References: <071.b310bd48623437f14cbd53de66531989@localhost> Message-ID: <080.c16b1170b60e00ba5e50b75819868d25@localhost> #1584: problem presenting with explicit pattern matching -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by guest): /sigh. Thanks, igloo. Sorry to use you as code reviewer. :( I see now where I started following an output pattern instead of thinking about the transform. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 16:20:33 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 16:12:41 2007 Subject: [GHC] #1586: trace output ordering in HEAD incorrectly In-Reply-To: <071.4112f64953d4f857c8564af2c7d5bffc@localhost> References: <071.4112f64953d4f857c8564af2c7d5bffc@localhost> Message-ID: <080.01460f5ae48270146ececb3383a2c03c@localhost> #1586: trace output ordering in HEAD incorrectly ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by igloo): * resolution: => invalid * status: new => closed Comment: It's generally unwise to rely on the order that trace's will be evaluated, and thus their output displayed. It could be that due to lazy evaluation the traces are necessarily evaluated in the opposite order to that which you expect, or if the strictness analyser has determined that the result is strict in both of them then it would not be a bug for either order to happen. Without a testcase I can't say more. Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 17:12:01 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 17:04:10 2007 Subject: [GHC] #1587: ":i (->)" doesn't work Message-ID: <071.563f845239453a6347ca7e47878984e4@localhost> #1587: ":i (->)" doesn't work ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ----------------------+----------------------------------------------------- {{{ Prelude> :i (->) :1:1: parse error on input `->' }}} I hope that's clear enough for you ;-). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 17:17:51 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 17:10:00 2007 Subject: [GHC] #1588: unrequested generalized newtype deriving? Message-ID: <071.972151299065a23e18b1972e1723034e@localhost> #1588: unrequested generalized newtype deriving? -----------------------+---------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- Consider the two type definitions: {{{ newtype MaybeT m a = MaybeT { runMaybeT :: m (Maybe a) } deriving Eq data MaybeT' m a = MaybeT' { runMaybeT' :: m (Maybe a) } deriving Eq }}} Why is it that the former compiles, with no flags of any kind, but the latter does not? It seems like generalized newtype deriving is happening when unrequested and undesired... (I'm trying to figure out how Derive should derive Eq, and compiler bugs don't help much ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 17:55:33 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 17:47:43 2007 Subject: [GHC] #1441: Evaluating undefined should return line number and module of location of undefined In-Reply-To: <071.b88dc21de802dc1580302b2a1f2115ff@localhost> References: <071.b88dc21de802dc1580302b2a1f2115ff@localhost> Message-ID: <080.f8871d23c8e9e217b06a401db7896493@localhost> #1441: Evaluating undefined should return line number and module of location of undefined ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by SamB): This sounds like John Meacham's "magic underscore" (see [http://repetae.net/john/computer/jhc/jhc.html the JHC documentation]). Then again, it also reminds me of the Haskell 98 report (see just above [http://www.haskell.org/onlinereport/standard-prelude.html#$vundefined undefined's definition]) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 17:57:08 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 17:49:17 2007 Subject: [GHC] #1341: allow loading partially correct modules In-Reply-To: <071.eedb2c8ad7257ddb194e2305097c4f31@localhost> References: <071.eedb2c8ad7257ddb194e2305097c4f31@localhost> Message-ID: <080.798500a774a16aedab049a07bcca3651@localhost> #1341: allow loading partially correct modules ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: module loading | Difficulty: Project (> 1 week) Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by SamB): Well, what if it only worked for things that parsed? How hard would that be? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 4 18:11:06 2007 From: trac at galois.com (GHC) Date: Sat Aug 4 18:03:17 2007 Subject: [GHC] #1576: Document Template Haskell API In-Reply-To: <071.fe24cb222d8cc4e4e9833aed813e408c@localhost> References: <071.fe24cb222d8cc4e4e9833aed813e408c@localhost> Message-ID: <080.04df66d63b9cffacdc9d55749a5dcf49@localhost> #1576: Document Template Haskell API ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by SamB): I second this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 5 14:13:34 2007 From: trac at galois.com (GHC) Date: Sun Aug 5 14:05:41 2007 Subject: [GHC] #1271: Vista: we need to add manifests to binaries to subvert installer-detection In-Reply-To: <071.6e5d4c6ccaf0c05166ab3ce3e0097f71@localhost> References: <071.6e5d4c6ccaf0c05166ab3ce3e0097f71@localhost> Message-ID: <080.127633ff148a803343a82a1e8117e590@localhost> #1271: Vista: we need to add manifests to binaries to subvert installer-detection -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Os: Windows | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by SamB): They ought to also check whether the executable is a console or GUI executable... probably that's a good indication of whether it's really a Windows installer or not... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 5 14:16:59 2007 From: trac at galois.com (GHC) Date: Sun Aug 5 14:09:06 2007 Subject: [GHC] #1460: Problem with Monoid instance of Data.Map In-Reply-To: <071.595b3870c3a1bb0bf6831ff29d2b6363@localhost> References: <071.595b3870c3a1bb0bf6831ff29d2b6363@localhost> Message-ID: <080.0cd41629baecc8b0713f446e2d4d69da@localhost> #1460: Problem with Monoid instance of Data.Map --------------------------------+------------------------------------------- Reporter: ahey@iee.org | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: Data.Map Monoid | Difficulty: Easy (1 hr) Os: Multiple | Testcase: Architecture: Multiple | --------------------------------+------------------------------------------- Comment (by SamB): I'm inclined to agree, though I recognize that the other way may well be useful too. There ought to be a way to warn people when you've changed instances like this... release notes, maybe? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 5 15:42:03 2007 From: trac at galois.com (GHC) Date: Sun Aug 5 15:34:09 2007 Subject: [GHC] #1271: Vista: we need to add manifests to binaries to subvert installer-detection In-Reply-To: <071.6e5d4c6ccaf0c05166ab3ce3e0097f71@localhost> References: <071.6e5d4c6ccaf0c05166ab3ce3e0097f71@localhost> Message-ID: <080.5443e0c1bcf8b8b95002d3754101cf3f@localhost> #1271: Vista: we need to add manifests to binaries to subvert installer-detection -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Os: Windows | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by neil): SamB: That's something that only MS could do, and even they can't do it retroactively! On Windows only .com executables are console ones, everything else is a Windows .exe, which may use the functions to bind to a console etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 05:42:43 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 05:34:48 2007 Subject: [GHC] #1589: Process creation and communication doesn't scale linearly Message-ID: <071.6ee8c05cb575856696bde08f6dbcdbca@localhost> #1589: Process creation and communication doesn't scale linearly -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.7 Severity: minor | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 -----------------------------+---------------------------------------------- Creating processes (with forkIO) and communicating between them (with putMVar and takeMVar) does not scale linearly. For 10000 processes creation takes 8us, but for 100000 it takes 60us. Even taking the increased GC into account it's highly non-linear. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 06:25:35 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 06:17:40 2007 Subject: [GHC] #1590: Libraries proposal: Add System.Info.isWindows Message-ID: <071.1058671fa9beaa1541cec4e05c346144@localhost> #1590: Libraries proposal: Add System.Info.isWindows ------------------------------+--------------------------------------------- Reporter: neil | Owner: Type: feature request | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- Currently the recognised way to test if your application is being run on Windows is: {{{ import System.Info .... = os == "mingw" }}} This is wrong on so many levels! # The return result of os is NOT an operating system # The result mingw does not imply that mingw is installed # String comparisons are not very safe, a typo stops this working # In GHC this comparison will take place at runtime, even though its a constant Since nearly all uses of System.Info.os are to check if the operating system is Windows, adding an explicit isWindows function would simplify things. Proposal: Add System.Info.isWindows :: Bool This value should return True on all Windows systems (Win 1.0 ... Vista), and False on all other systems. Deadline: 2 weeks from the end of discussion. Please discuss on the libraries@ mailing list. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 12:08:08 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 12:00:11 2007 Subject: [GHC] #1587: ":i (->)" doesn't work In-Reply-To: <071.563f845239453a6347ca7e47878984e4@localhost> References: <071.563f845239453a6347ca7e47878984e4@localhost> Message-ID: <080.6c834806fef10d4733751fe1749d138b@localhost> #1587: ":i (->)" doesn't work ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Changes (by Isaac Dupree): * version: 6.6 => 6.6.1 Comment: Also fails for me in 6.6.1. Since `:i []` works but not `:i ([])` (should this be true?), I tried `:i ->` and `:i ((->))` and `:i (a->b)` ... none of which worked. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 12:15:47 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 12:07:51 2007 Subject: [GHC] #1588: unrequested generalized newtype deriving? In-Reply-To: <071.972151299065a23e18b1972e1723034e@localhost> References: <071.972151299065a23e18b1972e1723034e@localhost> Message-ID: <080.8928efc6711187413f14c54879b4a4bd@localhost> #1588: unrequested generalized newtype deriving? -------------------------+-------------------------------------------------- Reporter: SamB | 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 | -------------------------+-------------------------------------------------- Changes (by Isaac Dupree): * version: 6.6 => 6.6.1 Comment: Hugs gives {{{ ERROR "t.hs":3 - Illegal Haskell 98 class constraint in derived instance *** Instance : Eq (MaybeT a b) *** Constraint : Eq (a (Maybe b)) }}} Which is much clearer (to me at least) than ghc's {{{ t.hs:4:8: No instance for (Eq (m (Maybe a))) arising from the 'deriving' clause of a data type declaration at t.hs:4:8 Possible fix: add an instance declaration for (Eq (m (Maybe a))) When deriving the instance for `Eq (MaybeT' m a)' }}} That is to say, Hugs refuses even the first one, as well as the second one. Your problem is that GHC is treating newtypes differently from data (neither of which fall within Haskell98 in this case). (I have no idea if this is a bug. It happens on 6.6.1 at least.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 12:28:50 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 12:20:53 2007 Subject: [GHC] #1588: unrequested generalized newtype deriving? In-Reply-To: <071.972151299065a23e18b1972e1723034e@localhost> References: <071.972151299065a23e18b1972e1723034e@localhost> Message-ID: <080.6048cfe06db40c428e3dab8f8f801b3c@localhost> #1588: unrequested generalized newtype deriving? -------------------------+-------------------------------------------------- Reporter: SamB | 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 | -------------------------+-------------------------------------------------- Comment (by SamB): Yes. Refusing both was the expected behaviour -- sorry if I didn't make that clear. I didn't ask for any extensions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 12:32:03 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 12:24:06 2007 Subject: [GHC] #1587: ":i (->)" doesn't work In-Reply-To: <071.563f845239453a6347ca7e47878984e4@localhost> References: <071.563f845239453a6347ca7e47878984e4@localhost> Message-ID: <080.cd761f9c33daf9097ea92ba4d1cc01b8@localhost> #1587: ":i (->)" doesn't work ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Comment (by SamB): [] isn't an infix name, so I wouldn't really expect {{{:i ([])}}} to work. ({{{([])}}} is valid as an expression, but not as a name.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 13:12:55 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 13:05:00 2007 Subject: [GHC] #1552: GHCi thinks large list literals impossible? In-Reply-To: <071.e57450aa1762d18d550008c3277a2b6f@localhost> References: <071.e57450aa1762d18d550008c3277a2b6f@localhost> Message-ID: <080.af5c500736b583034b885fb10648a00f@localhost> #1552: GHCi thinks large list literals impossible? ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Changes (by SamB): * version: 6.6 => 6.6.1 Comment: This doesn't work in 6.6.1 either, though a different error message is given: {{{ Prelude> :set -fth Prelude> $(let s = replicate 26227 'x' in [| s |]) Loading package template-haskell ... linking ... done. ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-unknown-linux): linkBCO: >= 64k insns in BCO }}} Also, I was actually trying to use Derive to create some instance declarations (which I want to put in a file rather than compile), rather than just lifting a boring list into TH, but this code is much shorter. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 13:42:46 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 13:34:51 2007 Subject: [GHC] #1552: GHCi thinks large list literals impossible? In-Reply-To: <071.e57450aa1762d18d550008c3277a2b6f@localhost> References: <071.e57450aa1762d18d550008c3277a2b6f@localhost> Message-ID: <080.caf4907b0e5427fa3bcf53ae293f9cf0@localhost> #1552: GHCi thinks large list literals impossible? ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Changes (by SamB): * version: 6.6.1 => 6.7 Comment: Spencer Janssen ({{{sjanssen}}}) and Bertram Felgenhauer ({{{int-e}}}) tried this for me with GHC 6.7.20070719 and 6.7.20070805, respectively, and each got the same error as I got with 6.6.1. {{{int-e}} says that it still fails with only 6000. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 14:31:24 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 14:23:28 2007 Subject: [GHC] #789: BCOs can only have 64k instructions In-Reply-To: <071.e1b2a35b5f1ccff853831eae584b746f@localhost> References: <071.e1b2a35b5f1ccff853831eae584b746f@localhost> Message-ID: <080.c242b29d73f617d9ce38b05bc72d12da@localhost> #789: BCOs can only have 64k instructions ------------------------+--------------------------------------------------- Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Comment (by SamB): Couldn't you just chain BCOs together or something? Also see #1552 -- I seem to have accidentally made a duplicate of this bug (and #455). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 15:51:05 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 15:43:08 2007 Subject: [GHC] #1591: runghc, ghc rts or base implements unintuitive shell escaping in Windows Message-ID: <071.9e739ba64f8154bf549e0e7c1b989e10@localhost> #1591: runghc, ghc rts or base implements unintuitive shell escaping in Windows -----------------------+---------------------------------------------------- Reporter: eivuokko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- Parameters passed to script via runghc get malformed unintuitively. {{{ Commandline "C:\Program Files\" "C:\Program Files\" should give ["c:\\Program Files\\", "c:\\Program Files\\"] but gives ["c:\\Program Files\" c:\\Program","Files\""] }}} On Windows Vista, ghc is from Neil's installer: {{{ C:\Users\eivuokko\Documents\source\cabal2wix>copy con test.hs module Main where import System.Environment main = getArgs >>= print ^Z 1 file(s) copied. C:\Users\eivuokko\Documents\source\cabal2wix>runghc test "c:\Program Files\" "c: \Program Files\" ["c:\\Program Files\" c:\\Program","Files\""] C:\Users\eivuokko\Documents\source\cabal2wix>ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 15:59:26 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 15:51:30 2007 Subject: [GHC] #1591: runghc, ghc rts or base implements unintuitive shell escaping in Windows In-Reply-To: <071.9e739ba64f8154bf549e0e7c1b989e10@localhost> References: <071.9e739ba64f8154bf549e0e7c1b989e10@localhost> Message-ID: <080.c028e8f3e972402ad5432178556e669a@localhost> #1591: runghc, ghc rts or base implements unintuitive shell escaping in Windows -------------------------+-------------------------------------------------- Reporter: eivuokko | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.8 * priority: normal => high Comment: Thanks for the report! Looks like our commandline parser is getting confused by \" We should fix this for 6.8, and add this example to the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 19:23:46 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 19:15:53 2007 Subject: [GHC] #1592: Unexpected boxing in generated code Message-ID: <071.bc3f3179aa6e1e1cdbdd19cd49cc661a@localhost> #1592: Unexpected boxing in generated code -----------------------+---------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: minor | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- argument being passed around, but that GHC 6.6.1 isn't unboxing. In the following example both functions take a GHC.Base.Int, which I think should be an Int#. {{{ Rec { f60_rS5 :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Base.Int -> GHC.Base.Int [GlobalId] [Arity 2 NoCafRefs Str: DmdType LL] f60_rS5 = \ (v1_aWH :: GHC.Prim.State# GHC.Prim.RealWorld) (v2_aWI :: GHC.Base.Int) -> case $wccall_r2kv v1_aWH of wild_X2j { (# ds_d1V4, ds1_d1V3 #) -> case ds1_d1V3 of wild1_X2L { __DEFAULT -> f60_rS5 ds_d1V4 v2_aWI; (-1) -> v2_aWI; 10 -> f561_r2kx ds_d1V4 v2_aWI } } f561_r2kx :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Base.Int -> GHC.Base.Int [GlobalId] [Arity 2 NoCafRefs Str: DmdType LL] f561_r2kx = \ (v1_aWm :: GHC.Prim.State# GHC.Prim.RealWorld) (v2_aWn :: GHC.Base.Int) -> case $wccall_r2kv v1_aWm of wild_X2j { (# ds_d1V4, ds1_d1V3 #) -> case ds1_d1V3 of wild1_X2P { __DEFAULT -> case v2_aWn of wild2_a2du { GHC.Base.I# x_a2dw -> case wild1_X2P of wild3_X35 { __DEFAULT -> f60_rS5 ds_d1V4 (GHC.Base.I# (GHC.Prim.+# x_a2dw 1)); 10 -> f561_r2kx ds_d1V4 (GHC.Base.I# (GHC.Prim.+# x_a2dw 1)) } }; (-1) -> v2_aWn } } end Rec } }}} This code comes from a line counting program, I have attached the entire source. My character counting program does infer the correct strictness, although that is based on a single self-recursive function. The largest obvious difference is that the strictness depends on the two functions which call each other - does this impeed GHC's strictness analysis? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 19:25:00 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 19:17:02 2007 Subject: [GHC] #1592: Unexpected boxing in generated code In-Reply-To: <071.bc3f3179aa6e1e1cdbdd19cd49cc661a@localhost> References: <071.bc3f3179aa6e1e1cdbdd19cd49cc661a@localhost> Message-ID: <080.b5a064ae35be688cf2032304f4c9bacd@localhost> #1592: Unexpected boxing in generated code -------------------------+-------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by neil): Simon PJ replied: Very curious. It does indeed look as though the strictness analyser is confused; but it should certainly not be confused by mutual recursion. I'll definitely look into it. But don't hold your breath -- it's a very busy fortnight. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 19:25:53 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 19:17:55 2007 Subject: [GHC] #1592: Unexpected boxing in generated code In-Reply-To: <071.bc3f3179aa6e1e1cdbdd19cd49cc661a@localhost> References: <071.bc3f3179aa6e1e1cdbdd19cd49cc661a@localhost> Message-ID: <080.0b152bf1b9fbdbac677b97cd41012e13@localhost> #1592: Unexpected boxing in generated code -------------------------+-------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by neil): For the first paragraph of my report, read: I've got an inner loop that I think I can see is strict in the Int argument being passed around, but that GHC 6.6.1 isn't unboxing. In the following example both functions take a GHC.Base.Int, which I think should be an Int#. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 6 19:36:42 2007 From: trac at galois.com (GHC) Date: Mon Aug 6 19:28:45 2007 Subject: [GHC] #1427: GHC fails to compile with gcc 4.2.0 In-Reply-To: <071.2ede1c5d35d6ea6c128d115bac843a59@localhost> References: <071.2ede1c5d35d6ea6c128d115bac843a59@localhost> Message-ID: <080.347aad18807882e124af4f7fd44770b1@localhost> #1427: GHC fails to compile with gcc 4.2.0 -------------------------------------+-------------------------------------- Reporter: ismail@pardus.org.tr | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by Isaac Dupree): * cc: arekm@maven.pl Bulat.Ziganshin@gmail.com kyrab@mail.ru,rich.neswold@gmail.com haskell@gentoo.org => arekm@maven.pl Bulat.Ziganshin@gmail.com kyrab@mail.ru,rich.neswold@gmail.com haskell@gentoo.org id@isaac.cedarswampstudios.org Comment: now that gcc-4.2.1 is out, gcc-4.2's adoption will keep increasing amongst normal users... possibly such as me -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 7 01:34:19 2007 From: trac at galois.com (GHC) Date: Tue Aug 7 01:26:22 2007 Subject: [GHC] #1592: Unexpected boxing in generated code In-Reply-To: <071.bc3f3179aa6e1e1cdbdd19cd49cc661a@localhost> References: <071.bc3f3179aa6e1e1cdbdd19cd49cc661a@localhost> Message-ID: <080.e698b40f7a53a14624caf2eff85e64d2@localhost> #1592: Unexpected boxing in generated code -------------------------+-------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by chevalier@alum.wellesley.edu): This actually doesn't have to do with the mutual recursion; it happens because of the "IO hack" in the demand analyzer. As per comments in the dmdAnalAlt function in DmdAnal.lhs, what's happening is that the call to $wccall_r2kv is being recognized as an IO operation (based on its type); because an IO operation might terminate the program in a non-erroneous way, it wouldn't be correct to evaluate f60's arguments before the call to $wccall_r2kv. Now, in this case, $wccall_r2kv is just getchar(), which I don't think could possibly terminate the program, so maybe the IO hack needs to be made a little bit more specific... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 7 01:34:47 2007 From: trac at galois.com (GHC) Date: Tue Aug 7 01:26:50 2007 Subject: [GHC] #1592: Unexpected boxing in generated code In-Reply-To: <071.bc3f3179aa6e1e1cdbdd19cd49cc661a@localhost> References: <071.bc3f3179aa6e1e1cdbdd19cd49cc661a@localhost> Message-ID: <080.6546047f03ca94356fb7e5f92cdbfa46@localhost> #1592: Unexpected boxing in generated code -------------------------+-------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by guest): * cc: ndmitchell@gmail.com => ndmitchell@gmail.com, chevalier@alum.wellesley.edu -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 7 07:01:32 2007 From: trac at galois.com (GHC) Date: Tue Aug 7 06:53:36 2007 Subject: [GHC] #1593: runInteractiveProcess misbehaves when it gets invalid (eg. non-existent) working directory parameter Message-ID: <071.6492671dc9921a60b786cbe5d4d5621a@localhost> #1593: runInteractiveProcess misbehaves when it gets invalid (eg. non-existent) working directory parameter ----------------------------------------+----------------------------------- Reporter: tomasz.zielonka@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ----------------------------------------+----------------------------------- Example code: {{{ import System.Process main = do (_, _, _, commhand) <- runInteractiveProcess "echo" ["something"] (Just "/no/such/dir") Nothing exitCode <- waitForProcess commhand print exitCode }}} This happens on Linux with both 6.6 and the latest HEAD snapshot. I think the problem is in C code, in libraries/base/cbits/runProcess.c (6.6). Below are the important code fragments. Search for BUG HERE for a bug location. {{{ ProcHandle runInteractiveProcess (char *const args[], char *workingDirectory, char **environment, int *pfdStdInput, int *pfdStdOutput, int *pfdStdError) { ... switch(pid = fork()) { ... case 0: { pPrPr_disableITimers(); if (workingDirectory) { if (chdir (workingDirectory) < 0) { // BUG HERE: // Calling return here is bad idea here. This code // is run in the child process and returning makes the // child act as if it was the parent - strange things will // happen! return -1; } } ... /* the child */ if (environment) { execvpe(args[0], args, environment); } else { execvp(args[0], args); } } _exit(127); default: ... }}} I thought about sending a patch, but I'm not sure what the fix should be. Doing "_exit(SOMETHING)" instead of return seems to be better then returning, but I don't know what SOMETHING should be, and maybe there is a better solution. I think I've seen the same problem in another run*Process function in this C file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 7 13:58:39 2007 From: trac at galois.com (GHC) Date: Tue Aug 7 13:50:38 2007 Subject: [GHC] #1594: Better QuickCheck/HUnit integration Message-ID: <071.8a9a5b6d619e81b753fd8e0a1d0430a1@localhost> #1594: Better QuickCheck/HUnit integration --------------------------------+------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- Daniel Burrows in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355215 requests: Quickcheck and HUnit are both great tools for testing software, but it seems to be rather difficult to make them work together. In particular, since the signature of all the quickCheck interface functions is some variant on {{{ Testable a => a -> IO () }}} the only way to find out whether a test succeeded or failed is to read the terminal output. It would be ideal if !QuickCheck could generate HUnit assertion failures when a test failed (maybe by expanding the Config structure with "failure hooks"), but even just changing its signature to either {{{ Testable a => a -> IO Bool }}} returning True for success, or (slightly more ambitiously) {{{ Testable a => a -> IO (Maybe String) }}} returning Nothing for success and an error message otherwise would be enough to get basic integration working. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 7 14:38:34 2007 From: trac at galois.com (GHC) Date: Tue Aug 7 14:30:35 2007 Subject: [GHC] #1595: duplicate "not in scope" error when giving multiple vars type-signatures at once Message-ID: <071.70688b48956d6f9561dd5be4c81207d0@localhost> #1595: duplicate "not in scope" error when giving multiple vars type-signatures at once ---------------------------+------------------------------------------------ Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: minor | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ---------------------------+------------------------------------------------ (bug in 6.6.1 and 6.7) {{{ a, b :: Integer -> Tpyo a = undefined b = undefined }}} results in {{{ gw.hs:2:19: Not in scope: type constructor or class `Tpyo' gw.hs:2:19: Not in scope: type constructor or class `Tpyo' }}} Expected result: only one of the same error per location in file of mistake, not one per function being defined. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 7 14:48:32 2007 From: trac at galois.com (GHC) Date: Tue Aug 7 14:40:32 2007 Subject: [GHC] #1596: ghc-pkg --define-name is undocumented Message-ID: <071.5bc56778062475e7835b7b6ad530acd2@localhost> #1596: ghc-pkg --define-name is undocumented ------------------------------+--------------------------------------------- Reporter: eivuokko | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Documentation | Version: 6.6.1 Severity: trivial | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- In ghc 6.6.1 ghc-pkg --define-name is undocumented, except getting mentioned in ghc-pkg usage output. Is it meant to be stable interface? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 7 15:27:43 2007 From: trac at galois.com (GHC) Date: Tue Aug 7 15:19:43 2007 Subject: [GHC] #1593: runInteractiveProcess misbehaves when it gets invalid (eg. non-existent) working directory parameter In-Reply-To: <071.6492671dc9921a60b786cbe5d4d5621a@localhost> References: <071.6492671dc9921a60b786cbe5d4d5621a@localhost> Message-ID: <080.3f58189955a2b0a20dfd69e38b1c576c@localhost> #1593: runInteractiveProcess misbehaves when it gets invalid (eg. non-existent) working directory parameter ------------------------------------------+--------------------------------- Reporter: tomasz.zielonka@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------------------------+---------------------------