GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?component=libraries%2Fbase&milestone=7.6.1&group=status&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?component=libraries%2Fbase&milestone=7.6.1&group=status&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/4363
http://ghc.haskell.org/trac/ghc/ticket/4363#4363: openFile sharing permissions are inconsistent across platformsMon, 04 Oct 2010 09:28:38 GMTjystic<p>
System.IO.openFile seems to have inconsistent behaviour across platforms regarding file sharing permissions.
</p>
<p>
Given this program:
</p>
<pre class="wiki">{-# LANGUAGE CPP #-}
import System.IO
import System.Process
main = do
h <- openFile "file.txt" WriteMode
hPutStrLn h "Success! I can see the file's contents."
hFlush h
#ifdef mingw32_HOST_OS
system "type file.txt"
#else
system "cat file.txt"
#endif
hClose h
</pre><p>
Running under Ubuntu 10.04 / GHC 6.12.1, I get:
</p>
<pre class="wiki">$ runghc openFile.hs
Success! I can see the file's contents.
</pre><p>
Running under Windows 7 / GHC 6.12.3, I get:
</p>
<pre class="wiki">> runghc openFile.hs
The process cannot access the file because it is being used by another process.
</pre><p>
In my opinion the behaviour exhibited by Linux is preferable because it allows for log files to be written by long running processes. These log files can then be inspected externally while the Haskell process is still running.
</p>
<p>
The Snap Framework (snapframework.com) does this and it works great on Linux / Mac OS, but on Windows the log files cannot be viewed until after the server is shut down.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4363#changelog
http://ghc.haskell.org/trac/ghc/ticket/5205
http://ghc.haskell.org/trac/ghc/ticket/5205#5205: Control.Monad.forever leaks spaceThu, 19 May 2011 06:29:20 GMTakio<p>
The attached program, compiled with GHC 7.0.3, uses up all the memory. It runs in a constant space when compiled with GHC 6.12.3.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5205#changelog
http://ghc.haskell.org/trac/ghc/ticket/5741
http://ghc.haskell.org/trac/ghc/ticket/5741#5741: openFile should fail if null bytes are in the argumentTue, 03 Jan 2012 08:16:36 GMTVeinor<p>
If the argument to openFile contains a null byte, right now it silently truncates everything after the null byte. This could lead to a vulnerability if the programmer relies on the presence of an extension such as ".cfg" to prevent people from reading in, say, /etc/passwd.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5741#changelog
http://ghc.haskell.org/trac/ghc/ticket/7041
http://ghc.haskell.org/trac/ghc/ticket/7041#7041: GHC.Real.gcdInt is no longer optimized.Mon, 02 Jul 2012 11:35:43 GMTint-e<p>
This is a regression since ghc-7.2, related to <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5767" title="bug: Integer inefficiencies (closed: fixed)">#5767</a>. <tt>GHC.Real</tt> defines
</p>
<pre class="wiki">gcdInt :: Int -> Int -> Int
gcdInt a b = fromIntegral (gcdInteger (fromIntegral a) (fromIntegral b))
</pre><p>
which used to optimize to <tt>GHC.Integer.Type.gcdInt</tt>. But since <tt>fromInteger = integerToInt</tt> and <tt>fromIntegral = smallInteger</tt> are no longer inlined, this optimization is lost. This results in unecessary allocations.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7041#changelog
http://ghc.haskell.org/trac/ghc/ticket/7058
http://ghc.haskell.org/trac/ghc/ticket/7058#7058: Add strict version of modifySTRefSun, 08 Jul 2012 04:29:47 GMTjoeyadams<p>
We added strict versions of modifyIORef and atomicModifyIORef recently (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5926" title="feature request: Add strict versions of modifyIORef and atomicModifyIORef (closed: fixed)">#5926</a>), and STM has <a class="ext-link" href="http://hackage.haskell.org/packages/archive/stm/latest/doc/html/Control-Concurrent-STM-TVar.html#v:modifyTVar-39-"><span class="icon"></span>modifyTVar'</a> since stm-2.3.
</p>
<p>
This patch adds <tt>modifySTRef'</tt>, mostly copy-pasted from <tt>modifyIORef'</tt>. My ghc currently doesn't build, so I wasn't able to test it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7058#changelog
http://ghc.haskell.org/trac/ghc/ticket/7170
http://ghc.haskell.org/trac/ghc/ticket/7170#7170: Foreign.Concurrent finalizer called twice in some casesTue, 21 Aug 2012 00:30:28 GMTjoeyadams<p>
When <a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/latest/doc/html/Foreign-Concurrent.html#v:newForeignPtr"><span class="icon"></span>Foreign.Concurrent.newForeignPtr</a> is used, here's a case where the finalizer is called twice:
</p>
<pre class="wiki">{-# LANGUAGE ForeignFunctionInterface #-}
import Control.Concurrent
import Control.Exception (bracket)
import Foreign.Ptr (Ptr, intPtrToPtr)
import Foreign.ForeignPtr (ForeignPtr)
import qualified Foreign.Concurrent as FC
import qualified Foreign.ForeignPtr as FP
testForeignPtr_Concurrent :: Ptr a -> IO (ForeignPtr a)
testForeignPtr_Concurrent ptr = FC.newForeignPtr ptr (fin ptr)
fin :: Ptr a -> IO ()
fin ptr = putStrLn $ "finalizing " ++ show ptr
main :: IO ()
main = do
mv <- newEmptyMVar
bracket (testForeignPtr_Concurrent $ intPtrToPtr 1)
FP.finalizeForeignPtr $ \_ ->
-- hang, so the thread and foreign pointer get GCed
takeMVar mv
</pre><p>
This produces the following output:
</p>
<pre class="wiki">finalizing 0x0000000000000001
finalizing 0x0000000000000001
foreignptr: thread blocked indefinitely in an MVar operation
</pre><p>
This happens on GHC 7.4.2 and 7.6.0.20120810, with and without -threaded.
</p>
<p>
This can easily lead to segfaults when you have an FFI library that does this:
</p>
<pre class="wiki">create :: IO Object
create = do
ptr <- c_create
CObject <$> newForeignPtr ptr (finalize ptr)
finalize :: Ptr CObject -> IO ()
finalize ptr = do
...
destroy :: Object -> IO ()
destroy (Object fptr) =
finalizeForeignPtr fptr
</pre><p>
And application code does this:
</p>
<pre class="wiki">bracket create destroy $ \obj -> do
...
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7170#changelog
http://ghc.haskell.org/trac/ghc/ticket/915
http://ghc.haskell.org/trac/ghc/ticket/915#915: Implement list fusion using streams instead of foldr/buildThu, 28 Sep 2006 10:33:13 GMTsimonpj<p>
We'd like to try using the stream-fusion idea of Don Stewart, Duncan Coutts and Roman Leshchinskiy, and replace the (somewhat fragile) foldr/build stuff.
</p>
<p>
See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/876" title="bug: Length is not a good consumer (closed: fixed)">#876</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/915#changelog
http://ghc.haskell.org/trac/ghc/ticket/1816
http://ghc.haskell.org/trac/ghc/ticket/1816#1816: Add Data.Set.mapMaybeWed, 31 Oct 2007 19:54:24 GMTguest<p>
This function is also available for lists (from Data.Maybe) and Maps (Data.Set).
The semantics are straightforward:
</p>
<pre class="wiki">mapMaybe f = fromList . catMaybes . map f . toList
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1816#changelog
http://ghc.haskell.org/trac/ghc/ticket/3160
http://ghc.haskell.org/trac/ghc/ticket/3160#3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVarWed, 08 Apr 2009 11:08:05 GMTChrisKuklewicz<p>
Looking at the code for QSem, QSemN, and <a class="missing wiki">SampleVar?</a> shows they all use a "takeMVar" then "putMVar" programming idiom.
</p>
<p>
None of these are exception safe. An unlucky killThread will leave the MVar empty and cause the rest of the program to malfunction.
</p>
<p>
The solution is to rewrite them using withMVar and modifyMVar(_) to prevent the MVar from being left empty in the event of an exception.
</p>
<p>
Note: QSem also needs the bugfix in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3159" title="bug: QSem fails with negative quantities (closed: fixed)">#3159</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3160#changelog
http://ghc.haskell.org/trac/ghc/ticket/5538
http://ghc.haskell.org/trac/ghc/ticket/5538#5538: Foldable typeclass: make foldl' and foldr' class methodsSat, 08 Oct 2011 11:15:46 GMTguest<p>
Change the <tt>Data.Foldable</tt> module: move <tt>foldl'</tt> and <tt>foldr'</tt> functions into the <tt>Foldable</tt> type
class so they can be defined efficiently in the instance definitions.
</p>
<p>
See the discussion: <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2011-June/016488.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2011-June/016488.html</a>
</p>
<p>
The patch from the initial message is attached.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5538#changelog
http://ghc.haskell.org/trac/ghc/ticket/5593
http://ghc.haskell.org/trac/ghc/ticket/5593#5593: Proposal: Remove Num superclass of BitsSat, 29 Oct 2011 01:36:06 GMTbasvandijk<p>
This ticket summarizes the <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2011-October/016899.html"><span class="icon"></span>discussion</a> on the proposal to remove the <tt>Num</tt> superclass of the <tt>Bits</tt> type class.
</p>
<p>
The proposal is to:
</p>
<ul><li>Remove the <tt>Num</tt> superclass of the <tt>Bits</tt> type class.
</li></ul><ul><li>Remove the default implementations of <tt>bit</tt>, <tt>testBit</tt> and <tt>popCount</tt> since they use methods of <tt>Num</tt>.
</li></ul><ul><li>Export the following convenience functions from <tt>Data.Bits</tt>:
</li></ul><pre class="wiki">bitDefault :: (Bits a, Num a) => Int -> a
bitDefault i = 1 `shiftL` i
testBitDefault :: (Bits a, Num a) => a -> Int -> Bool
testBitDefault x i = (x .&. bit i) /= 0
popCountDefault :: (Bits a, Num a) => a -> Int
popCountDefault = go 0
where
go !c 0 = c
go c w = go (c+1) (w .&. w - 1) -- clear the least significant
</pre><p>
Attached are tickets for <tt>base</tt> and <tt>ghc</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5593#changelog
http://ghc.haskell.org/trac/ghc/ticket/5627
http://ghc.haskell.org/trac/ghc/ticket/5627#5627: Proposal: Add Applicative instances for the remaining monads in baseFri, 11 Nov 2011 17:57:10 GMTbasvandijk<p>
The only public monads in <tt>base</tt> that don't have <tt>Applicative</tt> instances
yet are: <tt>ReadP</tt>, <tt>ReadPrec</tt> and <tt>ArrowMonad</tt>. Because of the rule of least
surprise I would like to propose adding <tt>Applicative</tt> instances for
these monads.
</p>
<h2 id="Proposal">Proposal</h2>
<p>
Concretely I would like to propose adding the following to <tt>Control.Applicative</tt>:
</p>
<pre class="wiki">instance Applicative ReadP where
pure = return
(<*>) = ap
instance Alternative ReadP where
empty = mzero
(<|>) = mplus
instance Applicative ReadPrec where
pure = return
(<*>) = ap
instance Alternative ReadPrec where
empty = mzero
(<|>) = mplus
instance Arrow a => Applicative (ArrowMonad a) where
pure x = ArrowMonad (arr (const x))
ArrowMonad f <*> ArrowMonad x = ArrowMonad (f &&& x >>> arr (uncurry id))
instance ArrowPlus a => Alternative (ArrowMonad a) where
empty = ArrowMonad zeroArrow
ArrowMonad x <|> ArrowMonad y = ArrowMonad (x <+> y)
</pre><p>
And adding the following to <tt>Control.Arrow</tt>:
</p>
<pre class="wiki">instance Arrow a => Functor (ArrowMonad a) where
fmap f (ArrowMonad m) = ArrowMonad $ m >>> arr f
instance (ArrowApply a, ArrowPlus a) => MonadPlus (ArrowMonad a) where
mzero = ArrowMonad zeroArrow
ArrowMonad x `mplus` ArrowMonad y = ArrowMonad (x <+> y)
</pre><h2 id="Discussiondeadline">Discussion deadline</h2>
<p>
I don't think this is a controversial proposal and so I don't expect objections. Can we bend the rules a bit and shorten the discussion period so this can be integrated into the base library that comes with the upcoming <tt>ghc-7.4</tt>?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5627#changelog
http://ghc.haskell.org/trac/ghc/ticket/5667
http://ghc.haskell.org/trac/ghc/ticket/5667#5667: Data.Unique.Unique and Data.Graph.SCC are not instances of ShowTue, 29 Nov 2011 05:51:31 GMTjewillco<p>
These two types are not currently instances of <tt>Show</tt>, and having that would be useful for debugging. The instances can both be derived (even using <tt>deriving instance</tt> in a separate module).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5667#changelog
http://ghc.haskell.org/trac/ghc/ticket/5679
http://ghc.haskell.org/trac/ghc/ticket/5679#5679: Provide Arrow lift functions for Control.ArrowSun, 04 Dec 2011 20:51:31 GMTA1kmm<p>
It is currently difficult to build complex datastructures by combining arrows, because there are no lift functions defined on Arrow. These can be built easily from the class functions:
</p>
<pre class="wiki">liftArrow :: Arrow a => (c -> d) -> a b c -> a b d
liftArrow = (^>>)
liftArrow2 :: Arrow a => (c -> c' -> d) -> a b c -> a b c' -> a b d
liftArrow2 f a1 a2 = arr (\a -> (a, a)) >>> (a1 *** a2) >>> arr (\(a, b) -> f a b)
liftArrow3 :: Arrow a => (c -> c' -> c'' -> d) -> a b c -> a b c' -> a b c'' -> a b d
liftArrow3 f a1 a2 a3 = arr (\a -> (a, (a, a))) >>> (a1 *** a2 *** a3) >>> arr (\(a, (b, c)) -> f a b c)
liftArrow4 :: Arrow a => (c -> c' -> c'' -> c''' -> d) -> a b c -> a b c' -> a b c'' -> a b c''' -> a b d
liftArrow4 f a1 a2 a3 a4 = arr (\a -> (a, (a, (a, a)))) >>> (a1 *** a2 *** a3 *** a4) >>> arr (\(a, (b, (c, d))) -> f a b c d)
liftArrow5 :: Arrow a => (c -> c' -> c'' -> c''' -> c'''' -> d) -> a b c -> a b c' -> a b c'' -> a b c''' -> a b d
liftArrow5 f a1 a2 a3 a4 a5 = arr (\a -> (a, (a, (a, (a, a))))) >>> (a1 *** a2 *** a3 *** a4 *** a5) >>> arr (\(a, (b, (c, (d, e)))) -> f a b c d e)
</pre><p>
I suggest these be added to Control.Arrow.
</p>
<p>
elliott suggested (on #haskell on Freenode) that something like arr2 = arr . uncurry could be defined as a building block, from which the lift functions could be defined.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5679#changelog
http://ghc.haskell.org/trac/ghc/ticket/5699
http://ghc.haskell.org/trac/ghc/ticket/5699#5699: Use sharing in the Alternative instance of MaybeWed, 14 Dec 2011 11:47:24 GMTbasvandijk<p>
The <tt><|></tt> method of the <tt>Alternative</tt> instance of <tt>Maybe</tt> does not share its first argument when it could:
</p>
<pre class="wiki">instance Alternative Maybe where
empty = Nothing
Nothing <|> p = p
Just x <|> _ = Just x
</pre><p>
I propose to share this argument:
</p>
<pre class="wiki">instance Alternative Maybe where
empty = Nothing
Nothing <|> r = r
l <|> _ = l
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5699#changelog
http://ghc.haskell.org/trac/ghc/ticket/5926
http://ghc.haskell.org/trac/ghc/ticket/5926#5926: Add strict versions of modifyIORef and atomicModifyIORefSun, 11 Mar 2012 00:24:54 GMTjoeyadams<p>
It is easy to misuse modifyIORef and atomicModifyIORef due to their lack of strictness. For example, if you use an IORef as a counter, use modifyIORef to increment it, and never evaluate the value until the very end, your program will leak memory, and you may even get a stack overflow:
</p>
<pre class="wiki">ref <- newIORef 0
replicateM_ 1000000 $ modifyIORef ref (+1)
readIORef ref >>= print
</pre><p>
Today, I found a <a class="ext-link" href="https://github.com/vincenthz/hs-tls/pull/8"><span class="icon"></span>space leak in the tls package</a>. Repeatedly calling sendData would leak memory. It didn't take me long to find the cause once I noticed a module named "Measurement" used for gathering connection statistics. It used modifyIORef to update the Measurement structure. When I changed it to this:
</p>
<pre class="wiki">x <- readIORef (ctxMeasurement ctx)
writeIORef (ctxMeasurement ctx) $! f x
</pre><p>
the space leak went away.
</p>
<p>
A more subtle mistake can be made using atomicModifyIORef. Can you spot the problem with this code?
</p>
<pre class="wiki">atomicModifyIORef ref (\_ -> (new_value, ()))
</pre><p>
It's not incrementing anything, it's just replacing the value. However, it's still deferring evaluation of the function. This mistake was pointed out in <a class="ext-link" href="http://themonadreader.files.wordpress.com/2011/10/issue19.pdf"><span class="icon"></span>The Monad.Reader Issue 19</a>, where they suggested the following idiom:
</p>
<pre class="wiki">x <- atomicModifyIORef ref (\_ -> (new_value, ()))
x `seq` return ()
</pre><p>
Thus, I believe there should be strict variants of modifyIORef and atomicModifyIORef, if only to warn programmers of these pitfalls.
</p>
<p>
<tt>modifyIORef'</tt> is pretty straightforward: force the result of applying the function:
</p>
<pre class="wiki">modifyIORef' ref f = do
x <- readIORef ref
let x' = f x
x' `seq` writeIORef ref x'
</pre><p>
The only question is: would it be better to force <tt>x'</tt> after <tt>writeIORef</tt> instead of before it, in case a caller is trying to share the IORef among threads (which they shouldn't be)?
</p>
<p>
<tt>atomicModifyIORef</tt> is less straightforward. Should we force the values themselves? It is possible to avoid the space leak above without forcing either the new value or the return value:
</p>
<pre class="wiki">atomicModifyIORef' :: IORef a -> (a -> (a,b)) -> IO b
atomicModifyIORef' ref f = do
p <- atomicModifyIORef ref (\a -> let p = f a in (fst p, p))
p `seq` return (snd p)
</pre><p>
It also allows <tt>f</tt> to decide what to force. For example, with this definition of atomicModifyIORef', the following program prints 10000000 and does not leak memory:
</p>
<pre class="wiki">ref <- newIORef 0
replicateM_ 10000000 $
atomicModifyIORef' ref
(\n -> let n' = n + 1
in n' `seq` (n', undefined))
readIORef ref >>= print
</pre><p>
In the attached patch, I didn't implement atomicModifyIORef' this way. Instead, I made it force both the old and new values, and added a separate function called atomicWriteIORef that has the same signature as writeIORef, but is based on atomicModifyIORef.
</p>
<p>
I believe the real value of such functions is to warn programmers about these pitfalls.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5926#changelog
http://ghc.haskell.org/trac/ghc/ticket/5930
http://ghc.haskell.org/trac/ghc/ticket/5930#5930: add System.Environment.lookupEnv which returns Maybe instead of an exceptionMon, 12 Mar 2012 02:32:02 GMTelaforge<p>
getEnv throws an exception when the key isn't found, which is surprising and inconvenient. I'd prefer to change the signature of getEnv to return Maybe, but that will break people's code, so I'll settle for a new lookupEnv function.
</p>
<p>
It's been discussed on libraries@… and there was unanimous support.
</p>
<p>
Patches attached, the first cleans up mixed tabs and spaces (which I understand has been happening in ghc lately). The second adds the new function. Unfortunately I still can't get ghc to compile so it's untested for now. I'll keep trying with GHC, but I don't have a windows machine for testing.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5930#changelog
http://ghc.haskell.org/trac/ghc/ticket/5963
http://ghc.haskell.org/trac/ghc/ticket/5963#5963: Fixed format floating point conversion does not round to evenSat, 24 Mar 2012 15:45:54 GMTaugustss<p>
Conversion of floating point numbers to a fixed numbers of decimals should use round-to-even rather that rounding up when the number is right between two possible results.
</p>
<p>
E.g., printf "%.1f" 0.45 should produce "0.4" rather than "0.5".
</p>
<p>
The heart of the problem is in libraries/base/GHC/Float.lhs.
The roundTo function should be replaced by this
</p>
<pre class="wiki">
roundTo :: Int -> Int -> [Int] -> (Int,[Int])
roundTo base d is =
case f d True is of
x@(0,_) -> x
(1,xs) -> (1, 1:xs)
_ -> error "roundTo: bad Value"
where
b2 = base `quot` 2
f n _ [] = (0, replicate n 0)
f 0 e (x:xs) | x == b2 && e && all (== 0) xs = (0, []) -- Round to even when at exactly half the base
| otherwise = (if x >= b2 then 1 else 0, [])
f n _ (i:xs)
| i' == base = (1,0:ds)
| otherwise = (0,i':ds)
where
(c,ds) = f (n-1) (even i) xs
i' = c + i
</pre><p>
I also (as the original author of the code) note that the large parts of that module was taken verbatim from the hbc libraries without attribution. :)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5963#changelog
http://ghc.haskell.org/trac/ghc/ticket/6136
http://ghc.haskell.org/trac/ghc/ticket/6136#6136: gettimeofday should not be used to schedule timeoutsThu, 31 May 2012 13:13:40 GMTDanielWaterworth<p>
From what I can tell, <a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/GHC-Event-Clock.html#getCurrentTime"><span class="icon"></span>getCurrentTime</a> uses gettimeofday and is used in <a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/GHC-Event-Manager.html#registerTimeout"><span class="icon"></span>registerTimeout</a> for the purpose of scheduling timeouts. I recommend reading <a class="ext-link" href="http://blog.habets.pp.se/2010/09/gettimeofday-should-never-be-used-to-measure-time"><span class="icon"></span>this</a> for an explanation of why this isn't a good idea.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6136#changelog
http://ghc.haskell.org/trac/ghc/ticket/7012
http://ghc.haskell.org/trac/ghc/ticket/7012#7012: ForeignPtrContents isn't exportedTue, 19 Jun 2012 08:18:26 GMTrl<p>
GHC.<a class="missing wiki">ForeignPtr?</a> doesn't export <a class="missing wiki">ForeignPtrContents?</a>. This means that this function can't be given a signature in user code:
</p>
<p>
f (<a class="missing wiki">ForeignPtr?</a> _ x) = x
</p>
<p>
<a class="missing wiki">ForeignPtrContents?</a> should be exported, at least abstractly, although exporting the constructors, too, would be useful for low-level code.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7012#changelog
http://ghc.haskell.org/trac/ghc/ticket/7029
http://ghc.haskell.org/trac/ghc/ticket/7029#7029: Add System.Environment.getExecutablePathTue, 26 Jun 2012 06:04:11 GMTtibbe<p>
As agreed after the corresponding libraries@ discussion (<a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.libraries/17368"><span class="icon"></span>http://thread.gmane.org/gmane.comp.lang.haskell.libraries/17368</a>) we should add <tt>System.Environment.getExecutablePath</tt>. Attached is an implementation for OS X, Linux, and Windows, with a fallback to argv<a class="missing changeset" title="No changeset 0 in the repository">[0]</a> on other platforms.
</p>
<p>
The Windows implementation was written without access to a Windows machine, so someone will need to test it on Windows to make sure it compiles/works.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7029#changelog
http://ghc.haskell.org/trac/ghc/ticket/7047
http://ghc.haskell.org/trac/ghc/ticket/7047#7047: Add a Functor instance for Control.Exception.HandlerTue, 03 Jul 2012 19:29:40 GMTparcs<p>
This is the ticket that corresponds to the proposal found at <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2012-March/017671.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2012-March/017671.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7047#changelog
http://ghc.haskell.org/trac/ghc/ticket/7052
http://ghc.haskell.org/trac/ghc/ticket/7052#7052: Numeric types’ Read instances use exponential CPU/memoryFri, 06 Jul 2012 02:55:10 GMTandersk<p>
Computing
<dl class="wiki"><dt>read "1e99999999"</dt><dd>Int -- returns 0
</dd><dt>read "1e99999999"</dt><dd>Integer -- returns [REDACTED]
</dd><dt>read "1e99999999"</dt><dd>Float -- returns Infinity
</dd><dt>read "1e99999999"</dt><dd>Double -- returns Infinity
</dd></dl>
takes rather a lot of CPU time and memory, and adding more digits to the exponent makes it take exponentially more. In some applications, this behavior could be exploitable as a denial of service.
</p>
<p>
I’m not sure what the right solution is for Integer, but clearly all the other cases should be optimized to produce 0 or Infinity very quickly.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7052#changelog
http://ghc.haskell.org/trac/ghc/ticket/7067
http://ghc.haskell.org/trac/ghc/ticket/7067#7067: Add alignment-restricted ForeignPtr allocation actionsWed, 11 Jul 2012 13:49:55 GMTnicolast<p>
Whilst GHC.<a class="missing wiki">ForeignPtr?</a> exports some actions to allocate buffers containing an element of some type, or of some specific byte-length efficiently, and there's an implementation of newAlignedPinnedByteArray# used internally, there's no way to request such buffer of a given size and at a given alignment.
</p>
<p>
The ability to enforce a specific alignment for some memory buffer is important e.g. when working with SIMD instructions (which is my original use-case). My attempts to work-around the lack of this function failed miserably (with a reproducible test-case) as mentioned in <a class="missing changeset" title="No changeset 1 in the repository">[1]</a>.
</p>
<p>
<a class="missing changeset" title="No changeset 1 in the repository">[1]</a> <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2012-July/022579.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2012-July/022579.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7067#changelog
http://ghc.haskell.org/trac/ghc/ticket/7077
http://ghc.haskell.org/trac/ghc/ticket/7077#7077: Add an order-reversing newtype to Data.OrdSat, 14 Jul 2012 16:11:54 GMTAzel<p>
This is proposal to add an order-reversing newtype to Data.Ord by adding GHC.Exts's one, Down.
</p>
<p>
You'll find attached a patch implementing this re-export and the conversation thread may be found <a class="ext-link" href="http://haskell.1045720.n5.nabble.com/Proposal-add-an-order-reversing-newtype-to-Data-Ord-td5714005.html"><span class="icon"></span>here</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7077#changelog
http://ghc.haskell.org/trac/ghc/ticket/7135
http://ghc.haskell.org/trac/ghc/ticket/7135#7135: Data.Bits can still have default implementations for testBit, bit, and popCount by using -XDefaultSignaturesMon, 13 Aug 2012 01:28:16 GMTjoeyadams<p>
In commit f99cee0 of the base package, the Num constraint was removed from the Bits class. Because the default implementations of testBit, bit, and popCount required Num, the same commit made them external functions instead.
</p>
<p>
We can still have default implementations for these if we use the -XDefaultSignatures GHC extension:
</p>
<pre class="wiki">#ifdef __GLASGOW_HASKELL__
default bit :: Num a => Int -> a
bit = bitDefault
default testBit :: Num a => a -> Int -> Bool
testBit = testBitDefault
default popCount :: Num a => a -> Int
popCount = popCountDefault
#endif
</pre><p>
Whether we want to do this or not, I'm not sure.
</p>
<p>
Pro:
</p>
<ul><li>This is more convenient.
</li></ul><ul><li>This may prevent people from encountering runtime errors in existing code that does not have bit, testBit, and popCount implementations, where the author forgot to compile with -Wall .
</li></ul><p>
Con:
</p>
<ul><li>Users get away with writing less portable code, so those who do wish to use non-GHC will have more support work to do.
</li></ul><p>
The attached patch adds defaults for testBit, bit, and popCount, for GHC only. It does not update the documentation, though, so "Minimal complete definition" as-is would be misleading.
</p>
<p>
P.S.: This ticket is for GHC 7.6.1-rc1. That version tag is not available, though.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7135#changelog