July 2013 - ghc-tickets

Re: [GHC] #4479: Add Type Directed Name Resolution
by GHC 10 Jul '13

10 Jul '13

#4479: Add Type Directed Name Resolution --------------------------------------------+------------------------------ Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * cc: adam.gundry@… (added) Comment: See [wiki:/Records/OverloadedRecordFields/Plan]. Adam is on this. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8045: Move I/O manager benchmarks into the GHC tree
by GHC 10 Jul '13

10 Jul '13

#8045: Move I/O manager benchmarks into the GHC tree -----------------------------------------+--------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- When we developed the scalable I/O manager (i.e. the first version that used epoll) we wrote a bunch of benchmarks that were never moved to the GHC tree or integrated into the make system: https://github.com/tibbe/event/tree/master/benchmarks It would be nice to move this into the GHC tree to catch future regressions and use them when trying to make improvements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4001: Implement an atomic readMVar
by GHC 10 Jul '13

10 Jul '13

#4001: Implement an atomic readMVar ----------------------------+---------------------------------------------- Reporter: | Owner: ezyang simonmar | Status: closed Type: task | Milestone: 7.6.2 Priority: low | Version: 6.12.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): Hey @ezyang, would you mind also adding a non-blocking version? `tryAtomicReadMVar#`. Just discovered it would be handy in some code I'm working on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4001#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4001: Implement an atomic readMVar
by GHC 10 Jul '13

10 Jul '13

#4001: Implement an atomic readMVar ----------------------------+---------------------------------------------- Reporter: | Owner: ezyang simonmar | Status: closed Type: task | Milestone: 7.6.2 Priority: low | Version: 6.12.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): Replying to [comment:23 ezyang]: > I'd generally be in favor, though I wonder if libraries@ wants to talk about it first. Sure, do you want to propose it? One downside is that it will invalidate the bit in my book that talks about `readMVar`, but that's not a big deal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4001#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #703: all binaries built by ghc have executable stacks
by GHC 10 Jul '13

10 Jul '13

#703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: merge Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): Hm, that's not right. I'll need some of your assistance: please run `ghc --make example.hs -v -fforce-recomp -keep-tmp-files` (where example.hs is some trivial Haskell program) and look at the output. You should see something like: {{{ *** C Compiler: '/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce- memory-overheads' '-c' '/tmp/ghc1284_0/ghc1284_0.c' '-o' '/tmp/ghc1284_0/ghc1284_0.o' '-DTABLES_NEXT_TO_CODE' '-I/usr/lib/ghc/include' *** C Compiler: '/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce- memory-overheads' '-c' '/tmp/ghc1284_0/ghc1284_1.s' '-o' '/tmp/ghc1284_0/ghc1284_1.o' '-DTABLES_NEXT_TO_CODE' '-I/usr/lib/ghc/include' }}} if you scroll up a little bit. Run `readelf -S` on both of the object files and check if `.note.GNU-stack` is present. The bug I saw in HEAD was `/tmp/ghc1284_0/ghc1284_1.s` did not have the appropriate `.note.GNU- stack` applied. If you see something different maybe something else has changed between 7.6 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/703#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4001: Implement an atomic readMVar
by GHC 10 Jul '13

10 Jul '13

#4001: Implement an atomic readMVar ----------------------------+---------------------------------------------- Reporter: | Owner: ezyang simonmar | Status: closed Type: task | Milestone: 7.6.2 Priority: low | Version: 6.12.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): I'd generally be in favor, though I wonder if libraries@ wants to talk about it first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4001#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4001: Implement an atomic readMVar
by GHC 10 Jul '13

10 Jul '13

#4001: Implement an atomic readMVar ----------------------------+---------------------------------------------- Reporter: | Owner: ezyang simonmar | Status: closed Type: task | Milestone: 7.6.2 Priority: low | Version: 6.12.2 Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): Is there any reason not to make `readMVar` use `atomicReadMVar#`, and remove `atomicReadMVar`? In principle it changes the behaviour, because a `readMVar` can currently wake up a blocked `putMVar`, but I've never heard of anyone using `readMVar` like that. The fact that `readMVar` is currently non-atomic has always been an annoyance more than a feature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4001#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4479: Add Type Directed Name Resolution
by GHC 10 Jul '13

10 Jul '13

#4479: Add Type Directed Name Resolution --------------------------------------------+------------------------------ Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by guest): * difficulty: => Unknown Comment: What's the estimated difficulty of implementing TDNR? I have for a long time been interested in this language feature in particular and now I'm about to start on my master's thesis, which is about a semester of dedicated work. What got me so interested in this feature is that you have to repeat yourself in record syntax, like `data MyRecord = MyRecord { myRecordLength :: Int, myRecordWidth :: Int}` rather than just `data MyRecord = MyRecord { length :: Int, width :: Int}`. I found that frustrating and I wondered why nobody else have went ahead and implemented this language feature yet. Now I found myself with one semester of time to do something like this. Is there any high-level sketch of the implementation on top of SPJ's head? Or is it still not clear which approach is best for doing type checking and name resolution at the same time? Finally, if you think this is too difficult for a somebody who have not hacked ghc before. Would you suggest him to make a prototype in a smaller haskell compiler? Best, Arash Rouhani rarash(a)student.chalmers.se -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #703: all binaries built by ghc have executable stacks
by GHC 10 Jul '13

10 Jul '13

#703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: merge Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by juhpetersen): Yes, thanks! I applied the fix to the Fedora ghc-7.6.3 package but alas still see GNU_STACK set executable on the ghc executables and ./hello for example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/703#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 09 Jul '13

09 Jul '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 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 asr): I compiled Alex 3.0.5 and Happy 1.18.10 (the versions in the Haskell Platform 2013.2.0.0) with GHC 7.6.3 using the `-fwarn-lazy-unlifted- bindings` warning. The compilation didn't generate any warning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0