- ghc-tickets - Haskell.org

Re: [GHC] #3704: Using -shared without -dynamic should be rejected on linux
by GHC 12 Aug '15

12 Aug '15

#3704: Using -shared without -dynamic should be rejected on linux -------------------------------------+------------------------------------- Reporter: asuffield | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I am going to close this as it appears that `-dynamic-lib` is now available. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3704#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9143: feature request: way to set actual program argv
by GHC 12 Aug '15

12 Aug '15

#9143: feature request: way to set actual program argv ----------------------------------------------+---------------------------- Reporter: joeyhess | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Linux Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It's not currently possible to write a program with ghc that changes its argv, so as to change what the program name/parameters appear to be in ps. An example of a program that does this is sshd, which arranges for the process name to say which user it's serving. For example, "sshd: joey [priv]" I'd like to be able to write such programs using haskell too. Also, I have a haskell program that, due to the way it is executed, has a really horrible display in ps: /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker /android-git-annex- builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker /android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64 -linux-gnu/audit:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv /usr/local/propellor/propellor That's enough motivation for me to dig into this. :) In rts/RtsMain.c, progargv is set to point to argv. However, it's static, so this cannot be (ab)used from the FFI to change argv. So, a minimal change would be to make progargv not be static, and perhaps give it a more formal name or minimal FFI binding. A GHC-specific library could then use this to modify argv. The haskell interface I'm considering would be: displayArgv :: [String] -> IO () It would need to truncate strings to fit within the available argv space. (This would not affect the argv used by System.Environment, which is a copy of argv.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #597: Various error messages have inaccurate source locations
by GHC 12 Aug '15

12 Aug '15

#597: Various error messages have inaccurate source locations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: low | Milestone: ⊥ Component: Compiler | Version: None Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10768 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: None => fixed * related: => #10768 Comment: Closing as all but one of these issues have been resolved. The remaining issue will be tracked by #10768. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/597#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement
by GHC 12 Aug '15

12 Aug '15

#2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement -------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/pretty | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: | -------------------------------------+--------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"f903949beee3a4e0a925003b5553066c9f513c11/ghc" f903949/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f903949beee3a4e0a925003b5553066c9f513c11" Pretty: improving the space/time performance of vcat, hsep, hcat (#10735) After 5d57087e314bd484dbe14958f9b422be3ac6641a ("Pretty: fix a broken invariant"), T3294 showed 50% more max_bytes_used (#3294). After this commit, max_bytes_used is back to what it was before, and the test passes again. This is a backport of a bug fix by Benedikt Huber (#2393), from commit 1e50748beaa4bd2281d323b18ea51c786bba04a1 in the pretty library. From https://mail.haskell.org/pipermail/libraries/2008-June/009991.html: vcat (hsep,cat) is implemented in an unneccessarily strict way. We only get some output after all of vcat's arguments are evaluated and checked against being Empty. This can be improved by only checking the right argument of foldr against being Empty, and then applying an Empty-filter on the resulting Doc. Space improvement is obvious. The microbenchmark (code.haskell.org/~bhuber/Text/PrettyPrint/ HughesPJPerfCheck.hs) suggests that the improvements in time are remarkable too. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2393#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3294: Large compilation time/memory consumption
by GHC 12 Aug '15

12 Aug '15

#3294: Large compilation time/memory consumption -------------------------------------------------+------------------------- Reporter: pumpkin | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 7.4.1 Component: Compiler | Version: 6.10.3 Resolution: wontfix | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"f903949beee3a4e0a925003b5553066c9f513c11/ghc" f903949/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f903949beee3a4e0a925003b5553066c9f513c11" Pretty: improving the space/time performance of vcat, hsep, hcat (#10735) After 5d57087e314bd484dbe14958f9b422be3ac6641a ("Pretty: fix a broken invariant"), T3294 showed 50% more max_bytes_used (#3294). After this commit, max_bytes_used is back to what it was before, and the test passes again. This is a backport of a bug fix by Benedikt Huber (#2393), from commit 1e50748beaa4bd2281d323b18ea51c786bba04a1 in the pretty library. From https://mail.haskell.org/pipermail/libraries/2008-June/009991.html: vcat (hsep,cat) is implemented in an unneccessarily strict way. We only get some output after all of vcat's arguments are evaluated and checked against being Empty. This can be improved by only checking the right argument of foldr against being Empty, and then applying an Empty-filter on the resulting Doc. Space improvement is obvious. The microbenchmark (code.haskell.org/~bhuber/Text/PrettyPrint/ HughesPJPerfCheck.hs) suggests that the improvements in time are remarkable too. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3294#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages
by GHC 12 Aug '15

12 Aug '15

#9049: Expose srcLoc from the assertion architecture to allow better error messages ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- Assertions give great error messages by including file name and line, but they are disabled for optimisation. While there is a compiler flag to turn them on even in presence of optimisation, this is an awkward external way to simply attach a useful error location to something like `error`. It would be great if we could decouple getting the current `srcLoc` from assertions, and making it available for good error messages. It is currently possible to do this using TemplateHaskell (e.g. the `placeholders` package) or `CPP`, but both are inconvenient for technical reasons (such as breaking tooling) and do not enjoy widespread use. It seems a shame that the architecture for annotated error messages is already there, but only available through a mechanism that is disabled for optimisation (or at least "intended" to be disabled for optimisation). Notably, we have the same architecture available for pattern mach failures: {{{ f x | x > 0 = "foo" main = putStrLn (f (-1)) -- gives srcLoc'd pattern match error message }}} {{{ f x | x > 0 = "foo" f _ = error "f needs a positive number" main = putStrLn (f (-1)) -- does not give a srcLoc'd error message }}} It seems non-sensical that your try to write a better error message (here using `error`) yields in fact a less-helpful error message. I completely agree that one can aid bug-fixing by writing globally unique arguments to `error` or using TH, but from an engineering perspective, a little bit of help from the language/compiler side can improve the situation a lot, and in other languages this is acknowledged and used to everybody's benefit. There are some alternatives we might consider, such as * exposing `srcLoc :: String` that gives an `assert`-style location at the lexical position of its occurrence * adding an `error`-like function that behaves like `error` but also prints a source location Arguably `srcLoc :: String` breaks equational reasoning on the ''syntactic'' level, as `let x = srcLoc in (x, x)` and `(srcLoc, srcLoc)` have different values. However, looking at it from a program execution point of view, referential transparency is preserved since once compiled, any function using `srcLoc` will always return the same location. I believe that offering ''some'' kind of improvement over the dreaded `error` or `Prelude: undefined` should be easy to implement, but let's hear what the people who actually know the compiler think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

Re: [GHC] #1687: A faster (^)-function.
by GHC 12 Aug '15

12 Aug '15

#1687: A faster (^)-function. -------------------------------------+------------------------------------- Reporter: moonlite@… | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Prelude | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Runtime performance bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1687#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5273: error and undefined should print a location
by GHC 12 Aug '15

12 Aug '15

#5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Revisions: Phab:D861 -------------------------------------+------------------------------------- Changes (by edsko): * related: => 9049 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5273#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #624: Program location for thread error messages
by GHC 12 Aug '15

12 Aug '15

#624: Program location for thread error messages -------------------------------------+------------------------------------- Reporter: chak | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): It seems like the recently merge implicit-parameter-based stack-trace work (see Phab:D578) would be quite useful for this. Blocking actions could take an implicit `SrcLoc` which could be providing along with the error in the event of indefinite blocking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/624#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1404: allow more type signatures
by GHC 12 Aug '15

12 Aug '15

#1404: allow more type signatures -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: 6.6.1 checker) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: It seems like the Backpack work addresses much of this by explicitly defining the publicly available interface of a package. Otherwise, the CPP approach proposed in comment:1 seems pretty reasonable to be. If someone wants to take up this task and see whether there is consensus around allowing multiple signatures then feel free to reopen this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1404#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0