October 2014 - ghc-tickets

Re: [GHC] #7473: getModificationTime gives only second-level resolution
by GHC 10 Oct '14

10 Oct '14

#7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by redneb): I have a patch for this issue that is basically ready. The only thing preventing me from submitting it is the fact that when `getFileAttributesExStandard` was added in Win32 the version number was not bumped properly. Because of that, I cannot use the MIN_VERSION_Win32 macro which is needed in order to provide a version of `getModificationTime` that works with all version of the Win32 package. If you bump one of the first 3 components of the version number of Win32, then I will finish and submit my patch. See also [1]. [1] https://github.com/haskell/win32/issues/13 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7473#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 10 Oct '14

10 Oct '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): I've written up most of the points discussed so far on a wiki-page: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#U… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7473: getModificationTime gives only second-level resolution
by GHC 10 Oct '14

10 Oct '14

#7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@… (added) * keywords: => directory -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7473#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 09 Oct '14

09 Oct '14

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.6.1 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Another report of this bug: https://github.com/haskell- fswatch/hfsnotify/issues/51 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1257: Bytecode generator can't handle unboxed tuples
by GHC 09 Oct '14

09 Oct '14

#1257: Bytecode generator can't handle unboxed tuples -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: GHCi | Version: 6.6 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: dsrun014 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): The problem is at the boundary between compiled code and interpreted code. We have a few special-purpose stack frames that do the impedence matching between the two worlds, one for each return convention. The problem with unboxed tuples is that there aren't a fixed number of return conventions, so we can't cover all the cases with a few stack frames. I haven't thought about this for a long term, but perhaps there's a way to make a generic stack frame that takes some kind of descriptor to describe the convention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1257#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9649: symbols should/might be type level lists of chars
by GHC 08 Oct '14

08 Oct '14

#9649: symbols should/might be type level lists of chars -------------------------------------+------------------------------------- Reporter: ibotty | Owner: ibotty Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I thought I had seen that feature request in trac but did not find it. Sorry if I am wrong. A simple use case might be a type safe routing framework, e.g. {{{ get :: Route "/a/:id" $ do idA <- param :: Param "idA" ... }}} I spoke with pedro at hacberlin last weekend and he told me simonp and iavor might tell me where to start looking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9356: scanl does not participate in stream fusion
by GHC 07 Oct '14

07 Oct '14

#9356: scanl does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- nomeata came up with a fusing version of a strict `scanl'` in a comment on #9345. It's not entirely clear to me whether that's entirely safe, but a non-strict version of it for `scanl` would be, as both a good producer and good consumer, presumably made efficient using the same sorts of magic used in HEAD for `foldl`. The strict `scanl'` is obviously safe to write as a good consumer; only the production side remains to be proved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx
by GHC 07 Oct '14

07 Oct '14

#9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I am having problems building yi on 32 bit architectures (i386, hurd-i386, kfreebsd-i386) on Debian: {{{ Loading package parallel-3.2.0.4 ... linking ... done. Loading package reflection-1.2.0.1 ... linking ... done. Loading package split-0.2.2 ... linking ... done. Loading package utf8-string-0.3.7 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package zlib-0.5.4.1 ... linking ... done. Loading package lens-4.1.2.1 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package terminfo-0.3.2.5 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol __x86.get_pc_thunk.bx whilst processing object file /usr/lib/haskell-packages/ghc/lib/i386-freebsd- ghc-7.6.3/vty-5.2.1/libHSvty-5.2.1.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} (Full log at https://buildd.debian.org/status/fetch.php?pkg=yi&arch=kfreebsd-i386&ver=0.…) It does not happen on amd64. This happens on the Debian auto-builders and I did not reproduce it locally yet, but maybe someone can already tell me what’s wrong from looking at it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7015: Add support for 'static'
by GHC 07 Oct '14

07 Oct '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => new Comment: Taking out of patch status. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7015: Add support for 'static'
by GHC 07 Oct '14

07 Oct '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Here is the state of play on `StaticPtr`, as I understand it today, is this: * [https://ghc.haskell.org/trac/ghc/blog/simonpj/StaticPointers My blog post] represents, I believe, a consensus. * In that blog post, Plan A requires some support from `Typable`/`TypeRep`. A new wiki page [wiki:Typeable] describes a design to do exactly that. This will be new to most of you; take a look. * The [wiki:StaticPointers] wiki page is out of date; Matthieu and Facundo are planning to update it None of this amounts to a full Plan; but it does represent progress. I think Matthieu and Facundo are the main driving forces. I'm hoping that you (perhaps with help from others) will * work through the proposed design a bit more, to check that it does what you need; * develop a plan for how we can more from where we are to the new glorious story with minimum disruption * develop an implementation Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0