January 2016 - ghc-tickets

Re: [GHC] #431: runInteractiveProcess and closed stdin.
by GHC 06 Jan '16

06 Jan '16

#431: runInteractiveProcess and closed stdin. -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: closed Priority: low | Milestone: ⊥ Component: | Version: 6.4 libraries/process | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #5761 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #5761 Comment: For reference, this was fixed in the following commits. https://github.com/haskell/process/commit/4a804c27f2c1a1d2f331006e32229c437…: {{{ Author: simonmar <unknown> Date: Mon Aug 1 13:23:22 2005 +0000 [project @ 2005-08-01 13:23:22 by simonmar] Fix [ ghc-Bugs-1249226 ] runInteractiveProcess and closed stdin. }}} https://github.com/haskell/process/commit/9c553822abd15de9c1543820b8d9f070b…: {{{ Author: Simon Marlow <simonmar(a)microsoft.com> Date: Fri May 23 10:07:40 2008 +0000 Overhall System.Process - fix #1780: pipes created by runInteractiveProcess are set close-on-exec by default - add a new, more general, form of process creation: createProcess Each of stdin, stdout and stderr may individually be taken from existing Handles or attached to new pipes. Also it has a nicer API (as discussed on libraries(a)haskell.org) - add readProcess / readProcessWithExitCode, originally from Don Stewart's newpopen package. These functions behave like C's popen(). - Move System.Cmd.{system,rawSystem} into System.Process. Later we can depecate System.Cmd. - Don't use O_NONBLOCK for pipes, as it can confuse the process attached to the pipe (requires a fix to GHC.Handle in the base package). - Provide a way to close all the file descriptors in the new process (see #1415) - add a couple more tests for the new features - bump the version to 2.0 }}} https://github.com/haskell/process/commit/3e6acdd0d9f7a80bbe454d114fb192e0a…: {{{ Author: Simon Marlow <marlowsd(a)gmail.com> Date: Fri Dec 11 10:05:40 2009 +0000 Add comments re: #431 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/431#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11344: Rule "and/build" not firing
by GHC 06 Jan '16

06 Jan '16

#11344: Rule "and/build" not firing -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For this function {{{ isprime_1 :: Int -> Bool isprime_1 n = n >= 2 && ( and $ map (\t -> 0 < mod n t) $ [2 .. truncate $ sqrt $ fromIntegral n] ) }}} rule "and/build" is not firing with ghc-7.10.3. ghc-7.8.4 does fire the rule and produces much better (that is, non- allocating) code. I can get good code with 7.10 if I replace "and" by {{{ import GHC.Base (build) {-# RULES "und/build" forall (g::forall b.(Bool->b->b)->b->b) . und (build g) = g (&&) True #-} {-# NOINLINE und #-} und :: [Bool] -> Bool und = foldr (&&) True }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11344> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2140: cpuTimePrecision is wrong
by GHC 06 Jan '16

06 Jan '16

#2140: cpuTimePrecision is wrong -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > But maybe we should just give up, since CPUTime is not part of the Haskell report anymore. Keep the function cpuTimePrecision for backward compatibility, but change the docstring to say what it really does: return the number of picoseconds between clock ticks. This sounds reasonable to me. For the record, I believe the relevant Linux interface here is `clock_getres` (which itself only has nanosecond resolution at best). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2140#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5251: copyFile does not copy metadata
by GHC 06 Jan '16

06 Jan '16

#5251: copyFile does not copy metadata -------------------------------------+------------------------------------- Reporter: Orphi | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Core Libraries | Version: 7.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ekmett (added) * status: new => closed * resolution: => duplicate * milestone: 8.0.1 => Comment: Moved to https://github.com/haskell/directory/issues/40. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5251#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5376: Quotation in System.Process.system for Windows
by GHC 06 Jan '16

06 Jan '16

#5376: Quotation in System.Process.system for Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: snoyberg Type: bug | Status: closed Priority: low | Milestone: Component: Core Libraries | Version: 7.0.4 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ekmett (added) * status: new => closed * resolution: => duplicate * milestone: 8.0.1 => Comment: Moved to https://github.com/haskell/process/issues/51. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5376#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 05 Jan '16

05 Jan '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by rassilon): Replying to [comment:46 bgamari]: > > My understanding of this situation is that it is not an intrinsic limitation of PE. The relevant data structures are the `.edata` and `.idata` tables which are defined in sections 63 and 64 of the PE/COFF specification. The specification specifies that one means of referring to exported symbols is via a 16-bit ordinal. However, this is not the only way; if the lookup fails the loader will fall back to a standard name search. Indeed, Microsoft even explicitly says that ordinals [[https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx|are a legacy artifact]] and their use is discouraged in new code (this document describes the `.def` format, but the idea still applies), > Your understanding doesn't match my understanding of the PE/COFF specification. Page 75 of the 02/06/2013 version of the spec which is the page where the Export Ordinal Table of the `.edata` section is described. The section includes pseudo-code explaining how the SymbolRVA of a named symbol is determined: i = Search_ExportNameTable(ExportName); ordinal = ExportOrdinalTable[i]; SymbolRVA = ExportAddressTable[ordinal - ordinalBase]; So, the problem isn't with this pseudo-code, but the pseudo-code combined with the Export Ordinal Table being defined as: > > `The export ordinal table is an array of 16-bit indexes into the address table.` This is especially sad, since the Address Table Entries field of the Export Directory Table is 32 bits of data. The text you quote below is from the syntax of .DEF files explaining why 16-bit DLLs, didn't include exported symbol string names and utilized the ordinal number as the ONLY `API` between DLLs. The documentation you quote is recommending usage of string symbols for providing a cross-DLL `API` resolution and only using the ordinal `API` for legacy reasons. The documentation doesn't mean to imply that ordinals are optional (based on my reading of the PE/COFF sections about .edata). > > You can use @ordinal to specify that a number, and not the function name, will go into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don’t recommend exporting functions by ordinal unless your DLL’s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL. > -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 05 Jan '16

05 Jan '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"cdeefa44ac8e2452a691708715bd2157a7bf3f0e/ghc" cdeefa4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cdeefa44ac8e2452a691708715bd2157a7bf3f0e" ghc.mk: Add reference to Trac #5987 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4800: Memory Leak when Compiling qtHaskell
by GHC 05 Jan '16

05 Jan '16

#4800: Memory Leak when Compiling qtHaskell -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | developer.berlios.de/project/showfiles.php?group_id=10072 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid * os: Windows => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: Replying to [comment:3 mtreskin]: > Have the same problem on Linux amd64 with 64-bit GHC. Given that this issue was opened 5 years ago, no new reports have been made since, and [http://qthaskell.berlios.de/ qtHaskell] itself seems dead (There is https://github.com/keera-studios/hsQt, which does seem active), I'm going to close this issue. Resolution "invalid", because there is no way to reproduce (anymore). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4800#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2459: can't link haskell without "main" function, or -no-hs-main broken on windows?
by GHC 05 Jan '16

05 Jan '16

#2459: can't link haskell without "main" function, or -no-hs-main broken on windows? -------------------------------------+------------------------------------- Reporter: jvl | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Driver | Version: 6.8.2 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme * milestone: 8.0.1 => Comment: > the last example [from comment:1] should work. And it does (without `-fglasgow-exts` an `MyHelloWorld_stub.o`): {{{ $ ghc -c -o MyHelloWorld.o MyHelloWorld.hs $ ghc -optl-mwindows -no-hs-main -o winhello.exe winmain.c MyHelloWorld.o $ echo $? 0 }}} I'm going to assume this issue has been fixed a long time ago (ticket opened 7 year ago). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2459#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2459: can't link haskell without "main" function, or -no-hs-main broken on windows?
by GHC 05 Jan '16

05 Jan '16

#2459: can't link haskell without "main" function, or -no-hs-main broken on windows? -------------------------------------+------------------------------------- Reporter: jvl | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Driver | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): It seems the first issue is fixed. Without `-no-hs-main` we get a link error, as expected: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ ghc -c -o MyHelloWorld.o MyHelloWorld.hs $ ghc -o hello.exe mymain.c MyHelloWorld.o -fforce-recomp C:\msys64\tmp\ghc5784_0\ghc_4.o:ghc_3.c:(.text+0x0): multiple definition of `main' }}} With `-no-hs-main` it works: {{{ $ ghc -c -o MyHelloWorld.o MyHelloWorld.hs $ ghc -no-hs-main -o hello.exe mymain.c MyHelloWorld.o -fforce-recomp $ ./hello.exe Hello World }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2459#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0