- ghc-tickets - Haskell.org

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 06 Jan '16

06 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 06 Jan '16

06 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 06 Jan '16

06 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 06 Jan '16

06 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 06 Jan '16

06 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

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: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Documentation bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2140#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options
by GHC 06 Jan '16

06 Jan '16

#10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As discussed in this issue: https://github.com/commercialhaskell/stack/issues/680 stack is one example of a program that optimistically turned on "-N". Indeed, it feels like a reasonable and even safe option for a multithreaded program. Unfortunately, -N currently guarantees bad performance on large machines and especially on large machines with hyperthreading. Pretty much one should ship an executable with -N by default as of GHC 7.8 and 7.10 IMHO. Unfortunately, even if stack did get a speedup at, say, 4 or 8 cores, it would not be good to ship it with "-N8" either. This would be an unreasonable choice on small, one or two core machines. What we need is a way to say that the program can productively use parallelism up to a certain upper bound, but that fewer threads should be used if there are not enough cores available. I propose "-N<=8" as a potential syntax. Currently, this behavior can be achieved with `setNumCapabilities`/`getNumProcessors`, but I think it's worth a command line RTS option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10728> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

Re: [GHC] #2140: cpuTimePrecision is wrong (was: cpuTimePrecision is wrong for me on Windows (XP))
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: | 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) * failure: => None/Unknown * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: 8.0.1 => * os: Windows => Unknown/Multiple Comment: The module `CPUTime` is part of the [https://www.haskell.org/onlinereport/cputime.html Haskell 98 report] (but not the Haskell 2010 report). Computation `getCPUTime` returns the number of picoseconds of CPU time used by the current program. The precision of this result is given by `cpuTimePrecision`. This is the smallest measurable difference in CPU time that the implementation can record, and is given as an integral number of picoseconds. == getCPUTime == > getCPUTime always returns a multiple of 15625000000 http://stackoverflow.com/a/29164665 explains this as follows: the clock is updated 64 times per second, at the clock tick interrupt. Or in other words 1 / 64 = 0.015625 between ticks And `0.015625 seconds = 15625000000 picoseconds`. == cpuTimePrecision == The current implementation of `cpuTimePrecision` looks at the value of `clockTicks = clk_tck()` (see #7519), converted to picoseconds. On my Linux system, `clk_tck` calls `sysconf(_SC_CLK_TCK)` and always returns `100` (see `libraries/base/cbits/sysconf.c`, and note that `CLK_TCK` is only defined when `#undef __USE_XOPEN2K`, see `/usr/include/time.h` and `/usr/include/x86_64-linux-gnu/bits/time.h`). On Windows, `clk_tck` seems to always return `CLK_TCK = 1000` (see `./opt/ghc-7.10.3/mingw/x86_64-w64-mingw32/include/time.h`). These values don't seem related in any way to the precision of `getCPUTime`. From `man sysconf`: clock ticks - _SC_CLK_TCK The number of clock ticks per second. The corresponding vari‐ able is obsolete. It was of course called CLK_TCK. (Note: the macro CLOCKS_PER_SEC does not give information: it must equal 1000000.) According to this [http://stackoverflow.com/questions/19919881/sysconf-sc- clk-tck-what-does-it-return?rq=1#comment29641173_19919970 stackoverflow comment]: it's the number of times the timer interrupts the CPU for scheduling and other tasks, 100Hz is a common value, higher frequency equals higher timer resolution and more overhead. == Solution ? == > Does anyone happen to know where we can get real values for this for any platforms? I don't know, but on Windows, you can supposedly use [https://msdn.microsoft.com/en- us/library/windows/desktop/ms724394%28v=vs.85%29.aspx GetSystemTimeAdjustment]. Some more discussion here: http://lists.ntp.org/pipermail/questions/2011-September/030583.html. 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 issue was also discussed in this thread: https://mail.haskell.org/pipermail/libraries/2008-February/009305.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2140#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0