- ghc-tickets - Haskell.org

Re: [GHC] #3693: Show stack traces
by GHC 20 Feb '14

20 Feb '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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): I would really, really like a wiki page that explains all this. Reverse- engineering it from a 65-comment trail is very labour intensive. The wiki page can by all means point to the paper (preferably not behind a paywall), explain the principles, etc. That might not take many words -- if so, that's great! Meanwhile I will go back to the paper Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 20 Feb '14

20 Feb '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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 scpmw): > given a proposed Core-Core transformation, does the transformation meet the specfification or not? Simon covered the basic idea pretty well. From the transformation point of view, the general rule of thumb is that source notes want to stay on covered code (even if transformed), but don't care too much about new code getting added in ("soft scope"). So we can for example work with fusion by simply floating "upwards": {{{ src<1.hs> foldr k z (src<2.hs> build g) ===> src<1.hs> src<2.hs> g k z }}} Cost-centres would disallow this kind of transformation, as the new stacks have little to do with the old one. Source notes on the other hand want the transformation to still happen, so we just annotate the new expression with everything that appeared on the deconstructed source expression. The paper goes into (way) more detail here, but the short version is that while not always optimal, this approach is always legal. The only special case so far is `let`- and `case`-floating, where we run into the same problems as cost-centres (and use pretty much the same solution). Additionally we decide to not care too much about allocation costs at a number of points where it would have made things too messy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 20 Feb '14

20 Feb '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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 Tarrasch): Yes, it would maybe be less confusing if there was a separate ticket for Peter's initial patches. The ticket could be named "Implement an object code to source code mapping" or maybe just "Emit DWARF in NCG". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:64> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8786: libraries/primitive build failure on Solaris 10
by GHC 20 Feb '14

20 Feb '14

#8786: libraries/primitive build failure on Solaris 10 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.8.1-rc1 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Solaris 10 is distributed with GNU C 3.4.3 compiler. This compiler does not support -ftree-vectorize command-line option and so its cc1 process fails on it which also mean that ghc-cabal fails compiling primitive package. The solution is simple to remove the -ftree-vectorize for solaris although it'll penalize Solaris 11 which is distributed with GNU C 4.6.2. I've solved that and provided a patch to primitive project in a pull request here: https://github.com/haskell/primitive/pull/6 I've entered the bug here to also track it and lobby for this issue to be solved for 7.8.1 release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8754: :set +s always says space usage is 0 bytes
by GHC 20 Feb '14

20 Feb '14

#8754: :set +s always says space usage is 0 bytes ------------------------------------+--------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- :set +s always says space usage is 0 bytes {{{ ghci GHCi, version 7.8.20140130:... ... sumOfPrimes2 40000000 25 1677366278943 it :: Int (14.84 secs, 0 bytes) }}} setting to high as this is a regression -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8760: ghc 7.8: ghc-split not installed
by GHC 20 Feb '14

20 Feb '14

#8760: ghc 7.8: ghc-split not installed --------------------------------+------------------------------------------ Reporter: | Owner: MagnusTherning | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc1 Component: Build System | Operating System: Linux Keywords: | Type of failure: Installing GHC failed Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ These are the steps I run to build and install (to prepare for packaging): {{{ ./sync-all -r git://git.haskell.org get -b ghc-7.8 ./boot ./configure --prefix=/usr make -j 5 make DESTDIR=/path/to/prepackage/dir install }}} The build itself works fine, the installed binaries work for simple tests like compiling ''hello, world'', starting {{{ghci}}}, etc. However, building '''mtl''' failed with {{{ Configuring mtl-2.1.2... Building mtl-2.1.2... Preprocessing library mtl-2.1.2... [ 1 of 21] Compiling Control.Monad.Writer.Class ( Control/Monad/Write/Class.hs, dist/build/Control/Monad/Writer/Class.o ) ghc: could not execute: /usr/lib/ghc-7.8.0.20140204/ghc-split }}} So it seems ''ghc-split'' isn't installed by {{{make install}}}. It also isn't included in the output of {{{make binary-dist}}}. I've seen this on both ''x86'' and ''x86_64''. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #3693: Show stack traces
by GHC 20 Feb '14

20 Feb '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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 simonmar): Simon - the best place to start is Peter and David's paper from last year's Haskell Symposium: http://dl.acm.org/citation.cfm?id=2503788 I think the next level of detail is the comments in the code. If you point to places where more explanation is needed, I'm sure Peter will be happy to add it. This is orthogonal to other methods for stack tracing, including the existing cost-centre-stack profiling. What these patches do is establish a best-effort mapping from object code to source code, ''without affecting what code gets generated at all''. It should have zero effect on optimisation - that's the main point. Then we can use the information later to try to make sense of the stack, and for profiling. There are follow-on patches to add support for these. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:63> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8802: createProcess implictlitly escapes and quotes command line parameters
by GHC 20 Feb '14

20 Feb '14

#8802: createProcess implictlitly escapes and quotes command line parameters -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I've just run into severe usability issue with the `process` library. It turns out that it performs quoting and escaping of command line parameters. The result is that it is impossible to run many shell commands that contain "unsafe" characters: {{{ diff <(echo $ENV_FOO) <(echo $ENV_BAR) awk 'NR<=10' Foo.txt }}} because they are turned into some nonsense. The culprit is `translate` function in libraries/process/System/Process/Internal.hs. I'm not fixing this myself as I assume there was some motivation behind escaping and quoting. I'm assigning high priority as it makes impossible to create shell processes correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8802> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #3693: Show stack traces
by GHC 20 Feb '14

20 Feb '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 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): Thanks for the heads-up. Can anyone point me to a single write-up of * The basic idea * A specification, as precise as possible. (E.g. given a proposed Core- Core transformation, does the transformation meet the specfification or not? There are a lot of side conditions like "if `tickishSoftScope` then..." in the code.) * An overview of how the implementation works supported by examples. There are lots of related design ideas sketched here [wiki:ExplicitCallStack]. If there's a serious proposal to adopt this one, it would be helpful to have a write up in at least this level of detail, perhaps more. Maybe it exists already. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:62> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8806: Invalid constraints should fail to type check
by GHC 20 Feb '14

20 Feb '14

#8806: Invalid constraints should fail to type check -------------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- With ghc-7.6.3 the following code: {{{ f :: Int => Int f x = x + 1 }}} should fail to type check, but instead compiles and runs as if it was: {{{ f :: Int -> Int f x = x + 1 }}} With 7.8rc1 and git HEAD this results in an error: {{{ Expected a constraint, but ‛Int’ has kind ‛*’ In the type signature for ‛f’: f :: Int => Int }}} We should add a "shouldn't type check" test to avoid the possibilty of a regression. Also: {{{ g :: (Int => Show a) => Int g = undefined }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8806> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2