November 2013 - ghc-tickets

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:7 andersk]: > that’s going to confuse anyone who knows that the real encoding is `(exit code << 8) + signal` (which, say, Perl forces you to learn). btw, what do you mean by //real// encoding? I've looked a bit around and here's what I've found so far: Python's [http://docs.python.org/3/library/os#os.wait os.wait()] operation which seem to match Perl's encoding: //... exit status indication: a 16-bit number, whose low byte is the signal number that killed the process, and whose high byte is the exit status (if the signal number is zero); the high bit of the low byte is set if a core file was produced.// ...otoh, Wikipedia says regarding [http://en.wikipedia.org/wiki/Exit_status#POSIX POSIX Exit status]: //... SUS specifies that the low-order 8 bits of the status value contain the exit status ...// -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:6 simonmar]: > Unfortunately we can't add the right information to `ExitCode`, because it is a platform-independent type. The correct type already exists: it is called `System.Posix.ProcessStatus`. > > {{{#!hs > data ProcessStatus = Exited ExitCode > | Terminated Signal > | Stopped Signal > deriving (Eq, Ord, Show) > }}} > > Unfortunately whoever wrote this forgot to add a `Bool` to indicate a core dump in the `Terminated` constructor. We *could* fix that. for the record, this has been implemented in [dc29d55b30d95f0838499fb48217e1d22e39d07d/unix] (which is included in the recently released [hackage:unix-2.7.0.0]) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): It looks like the current HEAD still uses the ambiguous (128 + signal) return codes from comment:3. I don’t pretend to speak for the developers, but from the following comments it looks like everyone agrees that committing to this API would be a mistake. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3606: The Ord instance for unboxed arrays is very inefficient
by GHC 08 Nov '13

08 Nov '13

#3606: The Ord instance for unboxed arrays is very inefficient --------------------------------------------+------------------------------ Reporter: blarsen | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: libraries (other) | Version: 6.10.4 Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * keywords: array, performance, Ord => array * os: Linux => Unknown/Multiple * milestone: 7.6.2 => 7.10.1 Old description: > The Ord instance for unboxed arrays defined in Data.Array.Base results in > code that makes lots of heap allocations and is very slow. > > For the record, the Ord instance is defined as so in Data.Array.Base: > > {{{ > instance (Ix ix, Ord e, IArray UArray e) => Ord (UArray ix e) where > compare = cmpUArray > > {-# INLINE cmpUArray #-} > cmpUArray :: (IArray UArray e, Ix i, Ord e) => UArray i e -> UArray i e > -> Ordering > cmpUArray arr1 arr2 = compare (assocs arr1) (assocs arr2) > }}} > > The 'assocs' calls don't appear to be deforested away, and hence, when > using the Ord functions on unboxed arrays, the performance is bad to the > point of making them unusable. > > It seems reasonable to me that 'compare' for unboxed arrays could be > implemented strictly, in a tight loop, without any heap allocations at > all. New description: The Ord instance for unboxed arrays defined in `Data.Array.Base` results in code that makes lots of heap allocations and is very slow. For the record, the `Ord` instance is defined as so in `Data.Array.Base`: {{{#!hs instance (Ix ix, Ord e, IArray UArray e) => Ord (UArray ix e) where compare = cmpUArray {-# INLINE cmpUArray #-} cmpUArray :: (IArray UArray e, Ix i, Ord e) => UArray i e -> UArray i e -> Ordering cmpUArray arr1 arr2 = compare (assocs arr1) (assocs arr2) }}} The `assocs` calls don't appear to be deforested away, and hence, when using the `Ord` functions on unboxed arrays, the performance is bad to the point of making them unusable. It seems reasonable to me that `compare` for unboxed arrays could be implemented strictly, in a tight loop, without any heap allocations at all. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3606#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 08 Nov '13

08 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): ...is the current HEAD of [source:process] in a releasable state with respect to this ticket? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7206: Implement cheap build
by GHC 08 Nov '13

08 Nov '13

#7206: Implement cheap build -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): If we do this, don't forget to use `cheapBuild` for `repeat`. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4900: DEPENDS pragma
by GHC 08 Nov '13

08 Nov '13

#4900: DEPENDS pragma -------------------------------------+------------------------------------ Reporter: cdsmith | Owner: parcs Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_Depends | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * owner: => parcs Comment: Okay, great. I will try to create an extensive patchset. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4900#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8433: forkProcess masks async exceptions inside the child process
by GHC 08 Nov '13

08 Nov '13

#8433: forkProcess masks async exceptions inside the child process ------------------------------------+--------------------------------- Reporter: joeyh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Frankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi- threaded daemon that expects async exceptions to work as they usually would. FWIW, I have looked at several of the libraries on hackage that handle daemonization, and none of them seem to deal with this by explicitly unmasking exceptions when running the daemon IO action. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #8037: GHC panic when compiling unsafeCoerce
by GHC 08 Nov '13

08 Nov '13

#8037: GHC panic when compiling unsafeCoerce -------------------------------------------------+------------------------- Reporter: ghc@… | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: fixed | Version: 7.6.1 Operating System: MacOS X | Keywords: Type of failure: None/Unknown | Architecture: Test Case: stranal/should_compile/T8037 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: new => closed * testcase: => stranal/should_compile/T8037 * resolution: => fixed Comment: Thanks. I've robustified this. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8037#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8037: GHC panic when compiling unsafeCoerce
by GHC 08 Nov '13

08 Nov '13

#8037: GHC panic when compiling unsafeCoerce ---------------------------------+------------------------------------ Reporter: ghc@… | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+------------------------------------ Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"9441b7fbf952adf9a3a4402167ba40d8d2166d98/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="9441b7fbf952adf9a3a4402167ba40d8d2166d98" Test Trac #8037 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8037#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0