GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=closed&component=libraries%2Fbase&milestone=7.2.1&group=resolution&order=summary
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=closed&component=libraries%2Fbase&milestone=7.2.1&group=resolution&order=summary
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/1414
http://ghc.haskell.org/trac/ghc/ticket/1414#1414: CString marshalling functions do not perform the specified conversionTue, 05 Jun 2007 23:00:02 GMTross<p>
The <tt>CString</tt> and <tt>CStringLen</tt> marshalling functions are specified in the FFI addendum as performing a locale-based conversion, but this is not implemented.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1414#changelog
http://ghc.haskell.org/trac/ghc/ticket/5275
http://ghc.haskell.org/trac/ghc/ticket/5275#5275: Data.Typeable not backwards compatibleFri, 24 Jun 2011 22:52:15 GMTaugustss<p>
In ghc 7.1 the type name returned for prelude types has changed. It used to be Int, Integer, etc, but in ghc 7.1 it's GHC.Types.Int, GHC.Integer.Type.Integer, etc.
</p>
<p>
This has many drawbacks:<br />
</p>
<ul><li>The names are impossible to guess<br />
</li><li>The names are not backwards compatible<br />
</li><li>The names are not portable to other compilers<br />
</li><li>The names reveal implementation details that should be kept hidden
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5275#changelog
http://ghc.haskell.org/trac/ghc/ticket/4904
http://ghc.haskell.org/trac/ghc/ticket/4904#4904: Documentation for mkWeakIORef is misleadingWed, 19 Jan 2011 10:18:44 GMTadept<p>
Documentation for mkWeakIORef should mention that second value is used as finalizer (and not, say, as key or value).
</p>
<p>
Patch attached.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4904#changelog
http://ghc.haskell.org/trac/ghc/ticket/3480
http://ghc.haskell.org/trac/ghc/ticket/3480#3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communicationsTue, 01 Sep 2009 09:09:12 GMTguest<p>
Data.Typeable: Easily make Typeable keys pure(used in Eq), so that Typeable keys don´t vary from run to run. This permits an efficient storage of the keys in files and to be transmitted trough communications as well as processed without loss of efficiency. Actually gaining efficiency probably, since the keys caches are not necessary.
</p>
<p>
Currently, whenever the user needs to communicate types, he must transmit the full string name for each type. Moreover, in the reception, the programmer is forced to handle these full string keys for mapping types to handlers, in equality checks etc. if the type keys are pure, the efficiency of key handling can be keept across communications.
</p>
<p>
short description of task:
Istead of using a Hash( stringType, generatedKey) use hashString (string-of-type)
</p>
<p>
Long description:
</p>
<p>
1) drop the cache; drop newKey
</p>
<p>
2) use instead the expression:
</p>
<pre class="wiki"> Key $ hashString str
</pre><p>
whenever a new key is needed from the package <tt>Data.HashTable</tt>:
</p>
<pre class="wiki">hashString :: String -> Int
</pre><p>
the key obtained is pure so:
</p>
<p>
3) drop the "IO" in <tt>typeRepKey</tt> signature
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3480#changelog
http://ghc.haskell.org/trac/ghc/ticket/4248
http://ghc.haskell.org/trac/ghc/ticket/4248#4248: Poor error message when openFile fails to open named pipeTue, 10 Aug 2010 12:12:13 GMTKhudyakov<p>
openFile cannot open named pipe if no one reads on the other end and fails with particularly unhelpful error message. Quick googling shows that it opens file in non-blocking mode so failure to open is not bug per se, but this fact is not mentioned in documentation.
</p>
<p>
Example:
</p>
<ol><li>Create named pipe
<pre class="wiki">$ mkfifo /tmp/fifo
</pre></li></ol><ol start="2"><li>Now in GHCi:
<pre class="wiki">Prelude> openFile "/tmp/fifo" WriteMode
*** Exception: /tmp/fifo: openFile: does not exist (No such device or address)
</pre></li></ol>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4248#changelog
http://ghc.haskell.org/trac/ghc/ticket/5161
http://ghc.haskell.org/trac/ghc/ticket/5161#5161: Poor performance of division; unnecessary branchingThu, 28 Apr 2011 08:31:20 GMTrtvd<p>
In case an Int* is divided by a constant the compiled code contains unnecessary checks whether the value being divided is minBound. This check is necessary only if a value is being divided by -1 so that an exception would be thrown.
</p>
<p>
The branch can be removed by the GHC's optimiser after a small change: the two parts of the corresponding condition have to be flipped. This provides an opportunity to short-circuit this condition to 'false' without knowing the first argument (patch is attached).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5161#changelog
http://ghc.haskell.org/trac/ghc/ticket/5178
http://ghc.haskell.org/trac/ghc/ticket/5178#5178: RULES "minusFloat x x" and "timesFloat 0.0 x" break IEEE-754 compatibilitySun, 08 May 2011 07:28:20 GMTliyang<p>
In GHC/Base.lhs, a comment around line ~778 notes that the following rules for Doubles give the wrong answer for NaN:
</p>
<pre class="wiki">"minusDouble x x" forall x#. (-##) x# x# = 0.0##
"timesDouble 0.0 x" forall x#. (*##) 0.0## x# = 0.0##
"timesDouble x 0.0" forall x#. (*##) x# 0.0## = 0.0##
</pre><p>
However, immediately above are corresponding rules for Floats:
</p>
<pre class="wiki">"minusFloat x x" forall x#. minusFloat# x# x# = 0.0#
"timesFloat x 0.0" forall x#. timesFloat# x# 0.0# = 0.0#
"timesFloat0.0 x" forall x#. timesFloat# 0.0# x# = 0.0#
</pre><p>
These should probably be removed.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5178#changelog
http://ghc.haskell.org/trac/ghc/ticket/3307
http://ghc.haskell.org/trac/ghc/ticket/3307#3307: System.IO and System.Directory functions not Unicode-aware under UnixThu, 18 Jun 2009 01:13:23 GMTYitzGale<p>
Under Unix, file paths are represented as raw bytes in a String.
That is not user-friendly, because a String is supposed to be
decoded Unicode, and it is conventional in Unix to view those
raw bytes as encoded according to the current locale. In addition,
this is not consistent with Windows, where file paths are
natively Unicode and represented as such in the String.
(Well, they will be consistently once <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3300" title="bug: System.IO and System.Directory functions not Unicode-aware under Windows (closed: fixed)">#3300</a> is completed.)
</p>
<p>
On the other hand, this raises various complications (what about encoding errors, and what if encode.decode is not the identity due to normalisation, etc.)
</p>
<p>
The following cases ought to work consistently for all file operations
in System.IO and System.Directory:
</p>
<ul><li>A FilePath from getArgs
</li><li>A FilePath from getDirectoryContents
</li><li>A FilePath in Unicode from a String literal,
</li><li>A FilePath read from a Handle and decoded into Unicode
</li></ul><p>
See discussion in the thread <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3307#changelog
http://ghc.haskell.org/trac/ghc/ticket/2458
http://ghc.haskell.org/trac/ghc/ticket/2458#2458: Unknown symbol `_environ' on MacOS XMon, 21 Jul 2008 14:02:12 GMTIgorBoehm<p>
Shared libraries and bundles on MacOS X Leopard don't have direct access to environ (i.e. extern char <strong>environ), which is only available to the loader ld when a complete program is being linked. If direct access to environ is needed, the _NSGetEnviron() routine, defined in <crt_externs.h> can be used to retrieve the address of environ at runtime (<a class="ext-link" href="http://developer.apple.com/documentation/Darwin/Reference/ManPages/man7/environ.7.html"><span class="icon"></span>man environ(7)</a> see last paragraph in section PROGRAMMING).
</strong></p>
<p>
Two Libraries are affected by this - namely <a class="ext-link" href="http://darcs.haskell.org/packages/base/"><span class="icon"></span>base</a> and <a class="ext-link" href="http://darcs.haskell.org/packages/unix/"><span class="icon"></span>unix</a>. Both of these Libraries implement (duplicate code) access to environ:
</p>
<ul><li><a class="ext-link" href="http://darcs.haskell.org/packages/base/include/HsBase.h"><span class="icon"></span>base/include/HsBase.h</a>:
<pre class="wiki">* ToDo: write a feature test that doesn't assume 'environ' to
* be in scope at link-time. */
extern char** environ;
INLINE char **__hscore_environ() { return environ; }
</pre></li><li><a class="ext-link" href="http://darcs.haskell.org/packages/unix/include/HsUnix.h"><span class="icon"></span>unix/include/HsUnix.h</a>
<pre class="wiki">extern char **environ;
</pre></li></ul><p>
Unfortunately this does not work on MaxOS X Leopard with XCode 3.0. My temporary workaround was to comment out the current definition of environ in the header files and add the following instead:
</p>
<ul><li>Hack for <a class="ext-link" href="http://darcs.haskell.org/packages/base/include/HsBase.h"><span class="icon"></span>base/include/HsBase.h</a>:
<pre class="wiki">/* ToDo: write a feature test that doesn't assume 'environ' to
* be in scope at link-time. */
//extern char **environ;
//INLINE char **__hscore_environ() { return environ; }
#include <crt_externs.h>
INLINE char **__hscore_environ(void) { return (*_NSGetEnviron()); }
</pre></li></ul><ul><li>Hack for <a class="ext-link" href="http://darcs.haskell.org/packages/unix/include/HsUnix.h"><span class="icon"></span>unix/include/HsUnix.h</a>:
<pre class="wiki">//extern char **environ;
#include <crt_externs.h>
INLINE char **__hsunix_environ (void) { return (*_NSGetEnviron()); }
</pre></li></ul><ul><li>Hack for <a class="ext-link" href="http://darcs.haskell.org/packages/unix/System/Posix/Env.hsc"><span class="icon"></span>unix/System/Posix/Env.hsc</a>:
<pre class="wiki">--getEnvironmentPrim :: IO [String]
--getEnvironmentPrim = do
-- c_environ <- peek c_environ_p
-- arr <- peekArray0 nullPtr c_environ
-- mapM peekCString arr
--
--foreign import ccall unsafe "&environ"
-- c_environ_p :: Ptr (Ptr CString)
getEnvironmentPrim :: IO [String]
getEnvironmentPrim = do
c_environ <- c_environ_p
arr <- peekArray0 nullPtr c_environ
mapM peekCString arr
foreign import ccall unsafe "__hsunix_environ"
c_environ_p :: IO (Ptr CString)
</pre></li></ul><p>
Unfortunately I do not know GHC well enough to propose a clean patch. With these 'hacks' ghc compiled from source on MacOS X Leopard with XCode 3.0 works well. It would also probably be good to get rid of the code duplication in the base and unix libraries.
</p>
<p>
Shall I open another Ticket for libraries/unix?
</p>
<p>
References:
</p>
<ul><li><a class="ext-link" href="http://developer.apple.com/documentation/Darwin/Reference/ManPages/man7/environ.7.html"><span class="icon"></span>environ man page</a>
</li><li><a class="ext-link" href="http://lists.apple.com/archives/Java-dev/2007/Dec/msg00096.html"><span class="icon"></span>response to similar problem on Apple Mailing List</a>
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/2458#changelog
http://ghc.haskell.org/trac/ghc/ticket/3304
http://ghc.haskell.org/trac/ghc/ticket/3304#3304: define gcd 0 0 = 0Mon, 15 Jun 2009 01:17:06 GMTstevec<p>
Please make any comments on the libraries list by Tuesday 15th September 2009.
</p>
<p>
A suggestion to change 'gcd 0 0' from<br />
gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"<br />
to<br />
gcd 0 0 = 0
</p>
<p>
The proposal has been discussed on haskell-cafe@…
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2009-May/060788.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2009-May/060788.html</a>
and there was a lot of support for the suggested change.
</p>
<p>
Current code:
libraries/base/GHC/Real.lhs
</p>
<pre class="wiki">-- | @'gcd' x y@ is the greatest (positive) integer that divides both @x@
-- and @y@; for example @'gcd' (-3) 6@ = @3@, @'gcd' (-3) (-6)@ = @3@,
-- @'gcd' 0 4@ = @4@. @'gcd' 0 0@ raises a runtime error.
gcd :: (Integral a) => a -> a -> a
gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"
gcd x y = gcd' (abs x) (abs y)
where gcd' a 0 = a
gcd' a b = gcd' b (a `rem` b)
</pre><p>
Suggested code:
</p>
<pre class="wiki">-- | @'gcd' x y@ is the greatest (positive) integer that divides both @x@
-- and @y@; for example @'gcd' (-3) 6@ = @3@, @'gcd' (-3) (-6)@ = @3@,
-- @'gcd' 0 4@ = @4@. @'gcd' 0 0@ is defined to be 0.
gcd :: (Integral a) => a -> a -> a
gcd x y = gcd' (abs x) (abs y)
where gcd' a 0 = a
gcd' a b = gcd' b (a `rem` b)
</pre><p>
[Note: I tried following the instructions at
<a class="ext-link" href="http://www.haskell.org/haskellwiki/Library_submissions"><span class="icon"></span>http://www.haskell.org/haskellwiki/Library_submissions</a>
to create a darcs patch. I successfully downloaded a copy of HEAD, but was unable to create a patch:
</p>
<p>
$ darcs record libraries/base/GHC/Real.lhs
Recording changes in "libraries/base/GHC/Real.lhs":
</p>
<p>
No changes in selected files or directories!
</p>
<p>
I would claim that the instructions are insufficient for a darcs beginner.
]
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3304#changelog
http://ghc.haskell.org/trac/ghc/ticket/2271
http://ghc.haskell.org/trac/ghc/ticket/2271#2271: floor, ceiling, round :: Double -> Int are awesomely slowThu, 08 May 2008 00:28:52 GMTdons<p>
We have super-naive implementations of the <a class="missing wiki">RealFrac?</a> class for Double.
</p>
<p>
Consider:
</p>
<pre class="wiki">
{-# RULES "truncate/Double->Int" truncate = double2Int #-}
instance RealFrac Double where
properFraction x
= case (decodeFloat x) of { (m,n) ->
let b = floatRadix x in
if n >= 0 then
(fromInteger m * fromInteger b ^ n, 0.0)
else
case (quotRem m (b^(negate n))) of { (w,r) ->
(fromInteger w, encodeFloat r n)
}
}
floor x = case properFraction x of
(n,r) -> if r < 0.0 then n - 1 else n
</pre><p>
So now, we *do* have a good rule for truncate, but floor, ceiling and round turn
out to be awesomely slow.
</p>
<pre class="wiki">main = print . sumU
. mapU (floor :: Double -> Int)
$ enumFromToFracU 0 100000000
</pre><p>
Runs in 1 minute, 10 seconds:
</p>
<pre class="wiki">$ time ./henning
5000000050000000
./henning 70.25s user 0.17s system 99% cpu 1:10.99 total
</pre><p>
Now, if we just replace that with a ccall to math.h:floor, we get:
</p>
<pre class="wiki">
main = print . sumU
. mapU (floor' :: Double -> Int)
$ enumFromToFracU 0 100000000
floor' :: Double -> Int
floor' x = (truncate :: Double -> Int) (c_floor x)
{-# INLINE floor' #-}
foreign import ccall unsafe "math.h floor"
c_floor :: Double -> Double
</pre><p>
Which runs in 1.8 seconds:
</p>
<pre class="wiki">
$ time ./henning
5000000050000000
./henning 1.88s user 0.00s system 99% cpu 1.884 total
</pre><p>
Similar results for ceiling and round (see the main ticket for <a class="missing wiki">RealFrac?</a>, <a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/1434"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/1434</a>)
</p>
<h2 id="Action">Action</h2>
<p>
Use math.h versions of round, floor and ceiling for Double and Float?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2271#changelog
http://ghc.haskell.org/trac/ghc/ticket/3309
http://ghc.haskell.org/trac/ghc/ticket/3309#3309: getArgs should return Unicode on UnixThu, 18 Jun 2009 01:29:59 GMTYitzGale<p>
The raw bytes of args should be decoded according to the current locale.
</p>
<p>
An additional function should be added:
</p>
<pre class="wiki">getArgsBytes :: IO [Word8]
</pre><p>
to provide access to the raw bytes.
</p>
<p>
This change needs to be coordinated with <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3007" title="bug: GHC seems to ignore the package name of modules imported with {#- SOURCE ... (closed: fixed)">#3007</a> so that it will still
work to read a file name from the command line args and use it
to access a file.
</p>
<p>
This change should also be made on Windows: <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3008" title="bug: Strange behavior when using newtyped version of IO monad in FFI import ... (closed: fixed)">#3008</a>
</p>
<p>
See the discussion at <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2009-June/062795.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3309#changelog
http://ghc.haskell.org/trac/ghc/ticket/3308
http://ghc.haskell.org/trac/ghc/ticket/3308#3308: getArgs should return Unicode on WindowsThu, 18 Jun 2009 01:19:07 GMTYitzGale<p>
This is what is expected, and it is needed for file
paths read from the command-line to work (once
<a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3300" title="bug: System.IO and System.Directory functions not Unicode-aware under Windows (closed: fixed)">#3300</a> is completed).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3308#changelog
http://ghc.haskell.org/trac/ghc/ticket/5060
http://ghc.haskell.org/trac/ghc/ticket/5060#5060: iteratee: epollControl: permission denied (Operation not permitted)Tue, 29 Mar 2011 08:54:06 GMTpacak<p>
If you run this ticket as literate haskell program it works fine when
</p>
<ol><li>executed via ghci/runhaskell in ghc 6.12.3
</li><li>executed as compiled file in both ghc 6.12.3 and 7.0.2/7.0.3
</li></ol><p>
and it fails with a message " epollControl: permission denied (Operation not permitted)" when executed via runhaskell in ghc 7.0.2/7.0.3
</p>
<pre class="wiki">> import Data.Iteratee
> import Data.Iteratee.IO
> import Data.Iteratee.Char
> main = fileDriver printLines "/etc/passwd"
</pre><p>
some logs are attached
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5060#changelog
http://ghc.haskell.org/trac/ghc/ticket/4805
http://ghc.haskell.org/trac/ghc/ticket/4805#4805: segfault in Data.HashTable, triggered by long Agda runsMon, 29 Nov 2010 23:18:36 GMTwkahl<p>
Agda uses <tt>Data.HashTable</tt> for interface (*.agdai) serialisation.
</p>
<p>
I have been able to localise a reproducible segfault (with one of the many theories in a sizeable Agda develoment) in <tt>Agda.TypeChecking.Serialise.encode</tt> inside the <tt>icode</tt> call, which essentially limits the possible source of the segfault to the Agda module <tt>Agda.TypeChecking.Serialise</tt> and to <tt>Data.HashTable</tt>.
</p>
<p>
Then I replaced all hash table uses in <tt>encode</tt> with <tt>Data.Map</tt>, and the Agda run in question finishes successfully.
(I confirmed with a selection of the theories that already could be type-checked with <tt>Data.HashTable</tt> that the {{Data.Map}}}-based version generates the same interface files.)
</p>
<p>
(Agda interface serialisation maintains four partial maps; their respective sizes at the end of this run are 151796,733,3319,0.)
</p>
<p>
I consider this as a (non-constructive) proof that there is a bug in <tt>Data.HashTable</tt>.
</p>
<p>
(For the time being, I need to make some long-delayed progress in my Agda developments and won't have time to try to debug <tt>Data.HashTable</tt>, but I should be able to occasionally test potential fixes.)
</p>
<p>
Wolfram
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4805#changelog
http://ghc.haskell.org/trac/ghc/ticket/2281
http://ghc.haskell.org/trac/ghc/ticket/2281#2281: properFraction implemented with modf primitive?Tue, 13 May 2008 13:54:22 GMTguest<p>
I need a fast 'fraction' function for Double.
I can use 'properFraction', but its Double instance uses 'decodeFloat', which is rather slow.
It's also clumsy to use, because I have to provide an Integral type, although I'm not interested in the integral part.
I can use (x - int2Double (double2Int x)) but this fails for x beyond the Int number range, and it is hard to fix that for an unknown implementation of Double.
</p>
<p>
What about a 'modf' primitive which either calls 'modf' from standard C library
or invokes an appropriate FPU command?
If Double is in IEEE format the 'fraction' command could also be implemented quite efficiently by some bit masking without the FPU.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2281#changelog
http://ghc.haskell.org/trac/ghc/ticket/4247
http://ghc.haskell.org/trac/ghc/ticket/4247#4247: getCPUTime on x86_64 Mac OS X 10.6Tue, 10 Aug 2010 00:12:01 GMTquark<p>
I have GHC 6.10.4 installed on a recent Mac Mini, which is running a 32-bit kernel (Snow Leopard, 10.6) but has 64-bit GHC installed, using <a class="missing wiki">MacPorts?</a>. I've compiled a very large commercial product with this installation (with FFI etc) and the product's testsuite passes, so I'm fairly confident that GHC is working ... except that "getCPUTime" is giving bogus values.
</p>
<p>
This simple program:
</p>
<pre class="wiki">import CPUTime
fn = do t <- getCPUTime
putStrLn ("t = " ++ show t)
fn
main :: IO ()
main = fn
</pre><p>
ought to produce increasing values of "t". However, the output jumps around wildly, from 10<sup>22</sup>, to 10<sup>24</sup>, to 10<sup>15</sup>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4247#changelog