March 2013 - ghc-tickets

[GHC] #7732: Allow killing of processes which are known by a System.Process.ProcessHandle
by GHC 13 Apr '13

13 Apr '13

#7732: Allow killing of processes which are known by a System.Process.ProcessHandle ----------------------------+----------------------------------------------- Reporter: timthelion | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/process Version: 7.4.2-rc1 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: ----------------------------+----------------------------------------------- There is no way to kill a process that is known only by it's ProcessHandle. That is, if I use createProcess to create a process, there is no way to kill it again. I can terminate it with terminateProcess but this is not the same. I would like to be able to kill processes as well. I think that something like this(completely untested change) would be good: https://github.com/timthelion/packages- process/commit/10ecc56682b9b71d3c196e47297b0f496cdc2bd7 https://github.com/timthelion/packages- process/commit/c4cdd064d7c154f41a5b2b7f73c6b0ac0b2dccb9 https://github.com/timthelion/packages- process/commit/1588100655f18bc2811edc0a5911e2b14a1ee411 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7732> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7725: Operators without colons
by GHC 13 Apr '13

13 Apr '13

#7725: Operators without colons ----------------------------------------+----------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- This code is accepted: {{{ data A x y = (&) x y }}} but it's wrong - as far as I know operators on the value level are constructors iff they start with a colon `(:&)`. (In fact {{{a = (&)}}} reports "Not in scope: (&)".) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7724: cross-compile to iOS
by GHC 13 Apr '13

13 Apr '13

#7724: cross-compile to iOS ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: 7700, 7705, 7707, 7709, 7718, 7720, 7721, 7722 Blocking: | Related: ------------------------------+--------------------------------------------- A bug for the whole task of cross-compiling to iOS, so we can block it by the individual tasks. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7698: thread blocked indefinitely in an MVar operation
by GHC 13 Apr '13

13 Apr '13

#7698: thread blocked indefinitely in an MVar operation -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.0.4 | Keywords: Os: Windows | Architecture: x86 Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------+---------------------------------------------------- This error occures after wake up from hibernation -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 13 Apr '13

13 Apr '13

#7695: Hang when locale-archive and gconv-modules are not there -------------------------+-------------------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 7.6.2 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- Running a (statically) compiled program in an environment where /usr/lib/locale or /usr/lib/gconv (or ../lib64/..) are not there, causes it to hog the CPU and rapidly allocate memory (this happens for example in an empty chroot). Steps to reproduce: {{{ echo "main = return ()" > test.hs ghc -static -optl-static -optl-pthread -o test test.hs chroot `pwd` /test }}} Strace output: {{{ $ /strace -e trace=file -e signal= /test execve("/test", ["/test"], [/* 17 vars */]) = 0 open("/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/locale/de_DE.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/locale/de_DE.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/locale/de_DE/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/locale/de.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/locale/de.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/locale/de/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) }}} Strace output (with LC_ALL=C): {{{ $ LC_ALL=C strace -e trace=file -e signal= /test execve("/test", ["/test"], [/* 18 vars */]) = 0 open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) }}} In both cases, there are no further system calls (apart from timer ticks and mmap). I was also able to reproduce this behavior without a chroot, by replacing the paths from strace's output with something nonexistent in the binary (manually, with a hex-editor). I didn't try dynamically linked binaries, yet. One problem ''may'' be, that iconv_open constantly returns -1 if it doesn't find the files listed above. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7695> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7687: ghc panic on TH and deriveJSON
by GHC 13 Apr '13

13 Apr '13

#7687: ghc panic on TH and deriveJSON -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 7.4.2 | Keywords: TH Os: Windows | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- {-# LANGUAGE CPP,TemplateHaskell #-} module Main (main) where import Data.Aeson.TH data Test = Test Int deriving Show deriveJSON id ''Test main = return () will give Building aeson-test-0.0.1... Preprocessing test suite 'test-aeson-test' for aeson-test-0.0.1... [1 of 1] Compiling Main ( src\Main.hs, dist\build\test-aeson- test\test-aeson-test-tmp\Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.0 ... linking ... done. Loading package bytestring-0.9.2.1 ... linking ... done. Loading package deepseq-1.3.0.0 ... linking ... done. Loading package containers-0.4.2.1 ... linking ... done. ghc.exe: panic! (the 'impossible' happened) Loading package text-0.11.2.3 ... linking ... done. (GHC version 7.4.2 for i386-unknown-mingw32): Loading package attoparsec-0.10.4.0 ... linking ... done. loadObj "C:\\Users\\User\\AppData\\Roaming\\cabal\\hashable-1.2.0.5\\ghc-7.4.2\\HShashable-1.2.0.5.o": failed Loading package blaze-builder-0.3.1.0 ... linking ... done. Loading package dlist-0.5 ... linking ... done. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Loading package hashable-1.2.0.5 ... ghc.exe: Unknown PEi386 section name `.text.startup' (while processing: C:\Users\User\AppData\Roaming\cabal\hashable-1.2.0.5\ghc-7.4.2\HShashable-1.2.0.5.o) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7730: :info and polykinds
by GHC 13 Apr '13

13 Apr '13

#7730: :info and polykinds -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ ghci -XPolyKinds Prelude> data A x y Prelude> :i A data A k k x y -- Defined at <interactive>:3:6 }}} The two `k` might be different. It should be either {{{A k l x y}}} or - without kind variables - {{{A x y}}}. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7685: :script command does not resolve ~
by GHC 13 Apr '13

13 Apr '13

#7685: :script command does not resolve ~ -----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Although the tab completion after ":script ~/..." would work, the command itself does not resolve ~ to the value of $HOME. This is counter- intuitive, and it would be nicer if ~ would work in parameters to :script. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7676: Conflicting definitions error for simple variable with guards
by GHC 13 Apr '13

13 Apr '13

#7676: Conflicting definitions error for simple variable with guards --------------------------------------+------------------------------------- Reporter: Mathnerd314 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following program: {{{ a | True = 1 a | False = 2 }}} produces an error (on 7.4.1 and 7.7.2012117): {{{ Conflicting definitions for 'a' }}} The following two examples produce no error: {{{ b | True = 1 | False = 2 c _ | True = 1 c _ | False = 2 }}} I would expect `a`, `b`. and `c ()` to have identical behaviour. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7676> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module
by GHC 13 Apr '13

13 Apr '13

#7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -----------------------------+---------------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.4.2 | Keywords: recursive modules, boot files, double vision, double vision problem Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- In a recursive module (i.e. a module that transitively imports itself), the unique "Name" of an entity E declared in this module's boot file should be precisely the same as that of the corresponding E defined in the module. Right now GHC appears to treat them as separate entities. (In the module systems literature, this problem has been identified as the "double vision problem" [1, Ch 5] and in general has caused problems with implementations of recursive modules. Derek Dreyer and his coauthors have proposed a number of solutions [2], and so have Im et al. more recently in the context of OCaml [3].) With that being said, the ''immediate'' problem here seems to be that GHC does not actually allow, in the implementing module, the import of its boot file's entities. There are a couple related errors I can identify with, huzzah!, very small example programs. The crux of the example is that the module A defines a data type T which is essentially the typical Nat data type -- except that the recursive type reference in the successor constructor refers to the "forward declaration's" view of the type (in the boot file) rather than the local view of that data type T. This first example shows that the boot file import is not actually making available the entities it declares: {{{ module A where data T }}} {{{ module A where import {-# SOURCE #-} qualified A as Decl(T) data T = Z | S Decl.T }}} The Decl.T reference should have the exact same identity as the locally defined T reference; after tying the module knot, this data type should be the same as if we had defined it with a T instead of Decl.T. However, the entity name T does not even appear to be gotten from the import of the boot file: {{{ A.hs:3:18: Not in scope: type constructor or class `Decl.T' }}} In an earlier version of GHC I tested, 6.12.1, the error message lies on the import statement: {{{ A.hs:2:44: Module `A' (hi-boot interface) does not export `T' }}} In the next example, with the same boot file, we see that the mechanism that checks whether the implementation matches the boot file fails to see the two "views" of T as the same. (Note that I changed the definition of T here to make the previous error go away.) {{{ module A(Decl.T(..)) where import {-# SOURCE #-} qualified A as Decl(T) data T = Z | S T }}} Since Decl.T should point to the same entity as T, the export statement should have the same effect as if it were instead "(T(..))". However, GHC again cannot make sense of the reference "Decl.T" and then complains that the boot file's T is not provided in the implementation: {{{ A.hs:1:10: Not in scope: type constructor or class `Decl.T' <no location info>: T is exported by the hs-boot file, but not exported by the module }}} (Making the export list empty shows this second error message only.) Altering this second example by omitting the alias on the import, and by changing the T reference in the type's definition to A.T, results in a well-typed module: {{{ module A(A.T(..)) where import {-# SOURCE #-} qualified A(T) data T = Z | S A.T }}} A final example shows that, in a module that is ''not'' the implementing module, entities defined in the boot file are imported as one would expect! In the following example, we insert a module B, in between A's boot file and A's implementation, which merely passes along the boot file's view of T. {{{ module A where data T }}} {{{ module B(Decl.T(..)) where import {-# SOURCE #-} qualified A as Decl(T) data U = U Decl.T }}} {{{ module A(T(..)) where import qualified B(T) data T = Z | S B.T }}} The error message here, again, lies in the reference B.T in A's implementation: {{{ A.hs:3:18: Not in scope: type constructor or class `B.T' Perhaps you meant `A.T' (line 3) }}} Notice, however, that the reference to Decl.T in the B module is perfectly well-formed. I suspect that the general problem lies with double vision, and that the more immediate problem--whereby imports of boot file entities from their implementing modules fail--is merely the manifestation of that. In the above, wherever I have suggested an intended semantics, I refer primarily to the state of the art in recursive modules systems. A perhaps more pressing justification, however, is that both the Haskell language report and Diatchki et al.'s specification of the module system [4] (seem to) corroborate that intended semantics. Your friend in the recursive module swamp,[[BR]] Scott Kilpatrick ---- References [1] Derek Dreyer. ''[http://www.mpi-sws.org/~dreyer/thesis/main.pdf Understanding and Evolving the ML Module System]'', PhD thesis, 2005.[[BR]] [2] Derek Dreyer. ''[http://www.mpi- sws.org/~dreyer/courses/modules/dreyer07.pdf A Type System for Recursive Modules]'', ICFP 2007.[[BR]] [3] Hyeonseung Im, Keiko Nakata, Jacques Garrigue, and Sungwoo Park. ''[http://dl.acm.org/citation.cfm?doid=2048066.2048141 A syntactic type system for recursive modules]'', OOPSLA 2011.[[BR]] [4] Iavor S. Diatchki, Mark P. Jones, and Thomas Hallgren. ''[http://web.cecs.pdx.edu/~mpj/pubs/hsmods.html A formal specification of the Haskell 98 module system]'', Haskell 2002. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4