December 2014 - ghc-tickets

[GHC] #9135: readProcessWithExitCode leaks when the program does not exist
by GHC 17 Feb '15

17 Feb '15

#9135: readProcessWithExitCode leaks when the program does not exist -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{#!haskell import Control.Monad import System.Process import qualified Control.Exception as C try' :: IO a -> IO (Either C.SomeException a) try' = C.try main = replicateM_ 1000 $ do try' (readProcessWithExitCode "doesnotexist" [] "") print =<< try' (readProcessWithExitCode "/bin/echo" ["it works"] "") }}} This eventually runs out of file descriptors and fails to start the existing process. Tested with process 1.2.0.0 and GHC 7.8.2 on OS X -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8844: Pseudo terminal and process-1.2.0.0
by GHC 17 Feb '15

17 Feb '15

#8844: Pseudo terminal and process-1.2.0.0 -------------------------------------+------------------------------------- Reporter: ksamborski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.6.3 Keywords: pty | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Hello, I'm writing simple app which execute process and communicate with it via pseudo terminal. Here is some sample code: import System.Posix.Terminal import System.Process main = do (master, slave) <- openPseudoTerminal hslave <- fdToHandle slave hSetBuffering hslave NoBuffering (_,_,_,ph) <- createProcess (shell "mc"){ env = Just [("TERM", "xterm")] , std_in = UseHandle hslave , std_out = UseHandle hslave , std_err = UseHandle hslave , close_fds = True } forkIO $ readTerm master -- my function which reads output from process waitForProcess ph The problem is that mc still wants some input from stdin but not from slave terminal. But when I changed function runIteractiveProcess from runProcess.c like this: ... /* Reset the SIGINT/SIGQUIT signal handlers in the child, if requested */ if (reset_int_quit_handlers) { struct sigaction dfl; (void)sigemptyset(&dfl.sa_ mask); dfl.sa_flags = 0; dfl.sa_handler = SIG_DFL; (void)sigaction(SIGINT, &dfl, NULL); (void)sigaction(SIGQUIT, &dfl, NULL); } /********************************************************************************/ setsid(); //Make the current process a new session leader ioctl(0, TIOCSCTTY, 1); //As the child is a session leader, set the controlling terminal to be the slave side of the PTY /********************************************************************************/ /* the child */ if (environment) { // XXX Check result execvpe(args[0], args, environment); } else { // XXX Check result execvp(args[0], args); } childFailed(forkCommunicationFds[1], forkExecFailed); ... it worked as expected, I'm not proposing patch or solution but is there any chance to add support for pseudo terminals in the process library? Maybe just add another record field in CreateProcess like pty :: Bool and then call these two additional instructions in runIteractiveProcess? Best regards, Karol Samborski -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8844> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9266: getDirectoryContents blow its stack in a huge directory
by GHC 17 Feb '15

17 Feb '15

#9266: getDirectoryContents blow its stack in a huge directory -------------------------------------------+------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- Once a directory has around 2 million files in it, a lack of an accumulator in getDirectoryContents (unix version only; windows already has an acc) causes it to blow the stack: {{{ joey@darkstar:‾/src/git-annex>cat test.hs import System.Directory main = do l <- getDirectoryContents "/tmp/big" print (null l) joey@darkstar:‾/src/git-annex>ghc --make -O2 test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... joey@darkstar:‾/src/git-annex>./test Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. }}} I suggest the attached patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9674: Foldable doesn't have any laws
by GHC 12 Feb '15

12 Feb '15

#9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The documentation for `Foldable` doesn't list any laws. I don't know exactly what its laws may be, but there are, at least, several implicit in the default method definitions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9213: CPP warnings on ghcautoconf.h
by GHC 09 Feb '15

09 Feb '15

#9213: CPP warnings on ghcautoconf.h ------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The cpphs program yields the following warning: {{{ Warning: trailing characters after #if directive in file ... /ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD }}} I guess it is necessary to replace `#if defined` by `#ifdef` in the line {{{ #if defined AC_APPLE_UNIVERSAL_BUILD }}} from the mk/config.h.in file. Note the next line `# if defined __BIG_ENDIAN__` has the same issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9337: Add `sortOn` function to Data.List
by GHC 09 Feb '15

09 Feb '15

#9337: Add `sortOn` function to Data.List -------------------------------------+------------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Easy (less Blocking: | than 1 hour) | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- This passed the vote on the libraries list a while ago, but I forget to add a ticket. The request was to add `sortOn` to `Data.List`: {{{ -- | Sort a list using a key on each element. This implements the -- decorate-sort-undecorate paradigm, also called a Schwarzian transform. sortOn :: Ord b => (a -> b) -> [a] -> [a] sortOn f = map snd . sortBy (comparing fst) . map (\x -> (f x, x)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9806: malloc and mallocArray ignore Storable alignment requirements
by GHC 08 Feb '15

08 Feb '15

#9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 8627 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Not sure if this is a bug or a feature request: `allocaBytesAligned` exists and allocates a new pinned byte array with a given alignment. It is used for both `alloca` and `allocaArray`. However, we don't currently have such a facility with `malloc`. `malloc` and `mallocArray` currently just invoke `mallocBytes`, and `mallocBytes` requests memory without alignment guarantees, so the resulting memory might well violate required `Storable` `alignment` for the result. We don't currently pad things out or get properly aligned memory. It strikes me that we should in theory add `mallocBytesAligned`, and switch `malloc` and `mallocArray` to invoke it instead of `mallocBytes`. `Foreign.Marshal.Alloc.mallocBytes` just invokes system `malloc`, so it seems that `memalign` or `posix_memalign` would be suitable. In theory `_malloc` on the system is probably aligning to a pretty common unit size, but if you start doing SIMD stuff you'll start seeing 16 byte alignment requirements, folks who care about cache architecture for example can have 128 byte alignments to pad things to separate cache lines. We probably haven't noticed since you likely get back bytes with slot- sized alignment just by construction, so if your alignment requirements stay in the <= 8 range you'll be okay, but for larger alignments it appears you'd just get wrong answers. If something more subtle is going on here (e.g. an `alignment` bigger than some threshold wont be respected or that users should explicitly expect `mallocArray` to silently allocate an array with the wrong alignment) that I missed then we definitely need better documentation to address the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9806> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9099: Add strict fmap
by GHC 06 Feb '15

06 Feb '15

#9099: Add strict fmap -------------------------------------------+------------------------------- Reporter: quchen | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Add a strict version of fmap to the standard libraries. {{{ infixl 4 <$!> (<$!>) :: Monad m => (a -> b) -> m a -> m b f <$!> m = do x <- m return $! f x {-# INLINE (<$!>) #-} }}} Libraries discussions: Take 1: http://www.haskell.org/pipermail/libraries/2013-November/021728.html Take 3: http://www.haskell.org/pipermail/libraries/2014-April/022864.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8796: -ddump-splices prints to error stream
by GHC 05 Feb '15

05 Feb '15

#8796: -ddump-splices prints to error stream -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- I just noticed that unlike other dump flags, `-ddump-splices` dumps to the error stream. I don't think this difference in behaviour is intended. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9004: Add sortOn function to Data.List
by GHC 05 Feb '15

05 Feb '15

#9004: Add sortOn function to Data.List -------------------------------------------+------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- The following passed for two weeks on the libraries mailing list without any dissenting votes. The request is to add the following function to Data.List: {{{ -- | Sort a list by comparing the results of a key function applied to each -- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the -- performance advantage of only evaluating @f@ once for each element in the -- input list. This is called the decorate-sort-undecorate paradigm, or -- Schwartzian transform. sortOn :: Ord b => (a -> b) -> [a] -> [a] sortOn f = map snd . sortBy (comparing fst) . map (\x -> let y = f x in y `seq` (y, x)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5