June 2014 - ghc-tickets

[GHC] #8529: Sequent reading from socket/connection on Windows fails
by GHC 24 Sep '14

24 Sep '14

#8529: Sequent reading from socket/connection on Windows fails -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.4.2 libraries/haskell2010 | Operating System: Windows Keywords: sockets, windows, | Type of failure: Incorrect result read failure | at runtime Architecture: Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- I wrote a simple TCP-client, which consumes and produces 8-byte packets. When I run it on linux, it works perfectly, being part of the loop (write- read-write-read-...). On windows it receives only first msg from the other side (write-read- write-write-...). The packets are still going, although. Before that, I used the sockets directly; changing to HandleStream didn't help. The code is: {{{ transmit :: Int -> HandleStream ByteString -> ByteString -> IO [Bytestring] transmit delay sock packet = do let input = timeout delay $ sock `readBlock` 8 <* putStrLn "\nData was read!" sock `writeBlock` pack strings <- whileJust input return [str | Right str <- strings] whileJust action = do result <- action case result of Just a -> (:) <$> return a <*> whileJust action Nothing -> return [] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8480: ghc 7.6.3 + clang-compatibility patches
by GHC 24 Sep '14

24 Sep '14

#8480: ghc 7.6.3 + clang-compatibility patches ----------------------------------------------+---------------------------- Reporter: darinmorrison | Owner: Type: task | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Moderate (less than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: ----------------------------------------------+---------------------------- I did a first pass at back-porting Austin's clang-compatibility patches from HEAD to 7.6.3 in anticipating of a 7.6.4 release, or at least some sort of update for OS X 10.9 folks. The back-ported commits are on branches in my GHC GitHub repo: https://github.com/darinmorrison/ghc ghc-7.6.3-clang (just clang stuff) ghc-7.6.3-clang+mavericks (clang stuff + 10.9 fixes) I haven't tested this fully yet, or even compiled it yet with the latest changes, but I think I caught most of the stuff that might cause problems. (Actually I just tried now and there's another error further along I still need to track down.) There are a few other rough edges still: warnings, etc. Also, if you want to use the validate script, you'll need to turn off Werror. Anyway, I'll try to get remaining stuff sorted out and get some binaries up in the next couple of days. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8480> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8251: Validate submodule references during pre-receive hook
by GHC 24 Sep '14

24 Sep '14

#8251: Validate submodule references during pre-receive hook ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 7.6.3 Keywords: admin git | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Right now, you can push a commit introducing a not-yet existing Git submodule commit reference. However, such commits can be rejected for submodule repositories hosted at git.haskell.org, thus forcing the user to push the submodule first, and only after that push the submodule-affecting commit in ghc.git This kind of sanity checking ghc.git commits will become more important, if more repositories are converted into Git submodules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8983: sync-all get should respect branches
by GHC 24 Sep '14

24 Sep '14

#8983: sync-all get should respect branches ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I have ghc-7.8 checked out and I do a './sync-all get', I might expect the repositories that are retrieved would also be set for ghc-7.8. However, this does not currently appear to be the case. This may be a little trickier, since if you're on a topic branch but you are mostly based off of master, then 'sync-all get' will fail, since the topic branch in question won't exist. So we should probably fall back in some way, rather than fail if the specified branch is not available. At the very least, we should print a warning if we sync-all get, the main branch is not master but we checked out a copy of master in the subrepo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8983> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8369: Small improvements to ./sync-all
by GHC 24 Sep '14

24 Sep '14

#8369: Small improvements to ./sync-all ------------------------------------+------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- ./sync-all get in a local clone does not use local submodules. That is, if I {{{ git clone ghc ghc-tmp; cd ghc-tmp; ./sync-all get }}} the contained clones come over just fine from ghc/... into ghc-tmp/..., but the submodules are fetched over the network connection. I think the attached patch brings the "fetch from the clone source if possible" behavior over to submodules, though possibly not in an ideal way. Separately, I find that I want to run shell commands in each repository; adding a "shell" verb is trivial and a second patch is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8897: Can't change "Full Name" in preferences
by GHC 24 Sep '14

24 Sep '14

#8897: Can't change "Full Name" in preferences ------------------------------------+------------------------------------- Reporter: novadenizen | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I mistyped my Full Name when I registered my account. I try to change it from preferences and I get an error message "Warning: The email address specified is already in use. Please specify a different one." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8897> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8070: Use a captcha for trac registrations
by GHC 24 Sep '14

24 Sep '14

#8070: Use a captcha for trac registrations ------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Use a captcha for trac registrations. These all seem to be 0.11-only: * http://trac-hacks.org/wiki/CaptchaAuthPlugin * http://trac-hacks.org/wiki/CaptchaAuthPlusPlugin * http://trac-hacks.org/wiki/SimpleCaptchaPlugin so the simplest answer might be recaptcha, although I believe that needs to be set up to be associated with a Google account: * http://trac-hacks.org/wiki/RecaptchaRegisterPlugin -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8836: ghc 7.6.3 (Linux) hangs on -O2
by GHC 23 Sep '14

23 Sep '14

#8836: ghc 7.6.3 (Linux) hangs on -O2 ------------------------------+-------------------------------------------- Reporter: tsuraan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC doesn't work at all Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I haven't had any luck finding a minimal test case for this, but the following replicates the issue on my two Linux machines running ghc 7.6.3: git clone https://github.com/tsuraan/optimal-blocks cd optimal-blocks git checkout bceee69f9f03d2e559f96cdf58412ada09c96a8c cabal sandbox init cabal install --only-dependencies cabal configure cabal build Cabal build will successfully build Algorithm.OptimalBlocks.SipHash and Algorithm.OptimalBlocks.BuzzHash, and it will attempt to build Algorithm.OptimalBlocks, but it will hang forever, using 100% of a single core. I have no idea how to debug this, but in src/Algorithm/OptimalBlocks.hs, if you replace the "in Blocks (reverse rlist) end" with "in Blocks [] bs", it will compile. Also, if that same file starts with the line "{-# OPTIONS_GHC -O1 #-}" it will compile. This also happens on my Mac running OSX 10.8.5 and ghc 7.4.2 without llvm; I have to tweak the .cabal file a little to drop the lower bound on base and to get rid of the "-fllvm" flag, but if I do that I see the exact same behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8836> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8918: Network package doesn't load under GHC 7.8 RC on windows (?)
by GHC 22 Sep '14

22 Sep '14

#8918: Network package doesn't load under GHC 7.8 RC on windows (?) -------------------------------------+--------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- (Please note that I am not certain that this issue is related to the 7.8 release candidate specifically, it may be some peculiarity of my system. But the same thing does work for me under 7.6.3 on the same machine. I don't understand exactly what the message is complaining about, so I don't feel confident in making a diagnosis. I don't know if the problem is me, the library, or ghc.) Under the GHC 7.8 rc1 build for Windows that I installed, I can't load the network package. In the course of upgrading one of my projects, I cabal install'd the network-conduit package, and network is one of the dependencies. The install worked fine, with the usual sprinkling of deprecation warnings and "rule might not fire because..." warnings, nothing that seemed unusual or alarming. I can't however actually load the package. {{{ GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.4.0 ... linking ... done. Loading package Win32-2.3.0.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.1 ... linking ... done. Loading package directory-1.2.0.2 ... linking ... done. Loading package base-unicode-symbols-0.2.2.4 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-base-0.4.1 ... linking ... done. Loading package monad-control-0.3.2.3 ... linking ... done. Loading package lifted-base-0.2.2.1 ... linking ... done. Loading package mmorph-1.0.2 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package resourcet-0.4.10 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package text-stream-decode-0.1.0.4 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package conduit-1.0.15.1 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package network-2.4.2.2 ... linking ... ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa ghc.exe: C:\Users\Doug\Documents\GitHub\bird-brain\.cabal-sandbox\x86_64 -windows-ghc-7.8.20140130\network-2.4.2.2\libHSnetwork-2.4.2.2.a: unknown symbol `WspiapiGetNameInfo' ghc.exe: unable to load package `network-2.4.2.2' }}} (The good bit was way at the end of a line, so repeated where you can see it...) {{{ network-2.4.2.2\libHSnetwork-2.4.2.2.a: unknown symbol `WspiapiGetNameInfo' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6

[GHC] #8097: internal error: getMBlock: mmap: Operation not permitted
by GHC 17 Sep '14

17 Sep '14

#8097: internal error: getMBlock: mmap: Operation not permitted ------------------------------+---------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+---------------------------------- I get the following: {{{ <interactive>: internal error: getMBlock: mmap: Operation not permitted (GHC version 7.4.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} when running {{{parseOnly queryKeyParse (Data.Text.pack "hello")}}} where: {{{ queryKeyParse :: Attoparsec.Parser [T.Text] queryKeyParse = do top <- Attoparsec.takeTill (=='[') keys <- many key return (top:keys) where key = many (Attoparsec.char '[') *> Attoparsec.takeTill (==']') <* many (Attoparsec.char ']') }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5