GHC: Ticket Queryhttp://ghc.haskell.org/trac/ghc/query?component=libraries%2Fbase&milestone=6.12.1&group=status&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.pnghttp://ghc.haskell.org/trac/ghc/query?component=libraries%2Fbase&milestone=6.12.1&group=status&order=priority
Trac 1.0.1http://ghc.haskell.org/trac/ghc/ticket/2793
http://ghc.haskell.org/trac/ghc/ticket/2793#2793: CLDouble is nothing like a long doubleWed, 19 Nov 2008 17:43:17 GMTjedbrown<p>
This affects all versions of GHC. Why does the type exist when it is just a synonym for CDouble? Either it should actually become a `long double' as the documentation says or it should just not exist. From Foreign/C/Types.hs:
</p>
<pre class="wiki">-- HACK: Currently no long double in the FFI, so we simply re-use double
-- | Haskell type representing the C @long double@ type.
FLOATING_TYPE(CLDouble,tyConCLDouble,"CLDouble",HTYPE_DOUBLE)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/2793#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2811
http://ghc.haskell.org/trac/ghc/ticket/2811#2811: Unicode support for text I/OTue, 25 Nov 2008 14:21:55 GMTigloo<p>
This means adding Unicode encoding/decoding for Text I/O handles.
</p>
<p>
Consensus was that Text I/O should always use the current locale encoding.
</p>
<p>
You can elect to have no encoding by opening in binary mode, but that's all.
</p>
<p>
Presumably this will need the ability to convert between arbitrary encodings internally, so it would make sense to also expose this functionality as a library.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2811#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3341
http://ghc.haskell.org/trac/ghc/ticket/3341#3341: encoding errors could be handled betterWed, 01 Jul 2009 18:39:44 GMTjudahj<p>
With the new Unicode I/O library, using the following program (<tt>badchar.hs</tt>):
</p>
<pre class="wiki">import System.IO
main = do
hSetBuffering stdin NoBuffering
getChar &gt;&gt; print
</pre><p>
If the terminal's LANG is utf-8 but a latin-1 non-ASCII character is
typed, then the terminal hangs and doesn't throw an error until three
more bytes are entered. Since <tt>NoBuffering</tt> is set, I'd expect the program to
immediately perform error handling rather than waiting for more input.
</p>
<p>
Furthermore, if the end of input is reached then the invalid byte is accepted without error. For example, in a utf-8 terminal:
</p>
<pre class="wiki">dhcp-19-155:tmp judah$ ghc -e "putStrLn \"\\249\"" | ./badchar
'\249'
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3341#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3469
http://ghc.haskell.org/trac/ghc/ticket/3469#3469: Error open file if name contain national symbolFri, 28 Aug 2009 15:43:43 GMTTonal<p>
Os Windows Vista Home Basic Ru + sp2
</p>
<p>
Steps
</p>
<ol><li>Haskell code (bug.hs in utf-8):
<pre class="wiki">main = do
con &lt;- readFile "фыва.txt"
print con
</pre></li></ol><ol start="2"><li>Console session:
<pre class="wiki">C:\Lang\test&gt;ghc -O3 --make bug.hs
C:\Lang\test&gt;echo asdf&gt;фыва.txt
C:\Lang\test&gt;bug.exe
bug.exe: DK20.txt: openFile: does not exist (No such file or directory)
</pre></li></ol>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3469#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3486
http://ghc.haskell.org/trac/ghc/ticket/3486#3486: Data.ByteString.elemIndices causes SEGVThu, 03 Sep 2009 11:39:31 GMTnwn<p>
The elemIndices for strict ByteString causes SEGV in some situation.
</p>
<pre class="wiki">import Data.Int
import qualified Data.ByteString as S
main = do
cs &lt;- S.getContents
let ps = S.elemIndices 10 cs
putStrLn $ "S.length cs = " ++ show (S.length cs)
putStrLn $ "length ps = " ++ show (length ps)
</pre><p>
If above program gets some large input, it crashes.
</p>
<pre class="wiki">$ ghc --make ei
[1 of 1] Compiling Main ( ei.hs, ei.o )
Linking ei ...
$ yes | head -10000 | ./ei
S.length cs = 20000
Segmentation fault
</pre><p>
By the way, there might be a border of SEGV or not.
</p>
<pre class="wiki">$ yes | head -4096 | ./ei
S.length cs = 8192
Segmentation fault
$ yes | head -4095 | ./ei
S.length cs = 8190
length ps = 4095
</pre><p>
And this script works fine.
</p>
<pre class="wiki">import qualified Data.ByteString as S
import qualified Data.ByteString.Lazy as L
main = do
let cs = S.pack . take 8192 . cycle $ [48,10]
ps = S.elemIndices 10 cs
putStrLn $ "length cs = " ++ show (S.length cs)
putStrLn $ "length ps = " ++ show (length ps)
</pre><p>
I think there is causes about the bug in S.getContents or S.elemIndices or both. But I cannot figure out it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3486#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3534
http://ghc.haskell.org/trac/ghc/ticket/3534#3534: hSetBinaryMode fails after some input has been readTue, 22 Sep 2009 16:45:32 GMTjudah<p>
For the following program (<tt>BadSeek.hs</tt>), type a couple characters of input and press return. With ghc-6.10.3, it works fine; with ghc-6.11 it throws an error.
</p>
<pre class="wiki">module Main where
import System.IO
main = do
getChar &gt;&gt;= print
hSetBinaryMode stdin True
getChar &gt;&gt;= print
</pre><p>
With ghc-6.10:
</p>
<pre class="wiki">$ ./BadSeek
ab
'a'
'b'
</pre><p>
With ghc-6.11:
</p>
<pre class="wiki">$ ./BadSeek
ab
'a'
BadSeek: &lt;stdin&gt;: hSetBinaryMode: illegal operation (cannot flush the read buffer of a text-mode handle)
</pre><p>
The error goes away if the first 'getChar' is commented out.
</p>
<p>
For libraries which are not yet using the Unicode I/O layer, having a way to temporarily set stdin to <tt>BinaryMode</tt> would be useful.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3534#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3614
http://ghc.haskell.org/trac/ghc/ticket/3614#3614: Cabal file parser can't handle colon in descriptionTue, 27 Oct 2009 14:39:48 GMTdsf<p>
The description field of the cabal file in the haskell-mtl package currently in debian sid contains an url with a colon, which leads to this error:
</p>
<pre class="wiki"> ghc-pkg: 13: unrecognised field or section: "(&lt;http://web.cecs.pdx.edu/~mpj/pubs/springschool.html&gt;),"
</pre><p>
This comes from <tt>Cabal.Distribution.ParseUtils</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3614#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3635
http://ghc.haskell.org/trac/ghc/ticket/3635#3635: base-3-compat with 6.12 won't load in GHCi, Template Haskell on WindowsTue, 03 Nov 2009 08:59:46 GMTguest<p>
base3-compat/GHC/Handle.hs needs:
</p>
<pre class="wiki">#ifndef mingw32_HOST_OS
..
#endif
</pre><p>
Wrapped around its export for and definition of unlockFile. This is because unlockFile is a RTS symbol that is only compiled on non-Windows OSes. This #ifdef exists in base4, it looks like it was just omitted from base3.
</p>
<p>
The result of this bug is that any package using base 3 doesn’t work with template-haskell or GHCi:
</p>
<pre class="wiki">$ ghci -package base-3.0.3.2
WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular)
doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead
GHCi, version 6.12.0.20091010: 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 syb-0.1.0.2 ... linking ... done.
Loading package base-3.0.3.2 ... linking ... : unable to load package `base-3.0.3.2'
: C:\ghc\GHC-61~2.200\lib\base-3.0.3.2\HSbase-3.0.3.2.o: unknown symbol `_unlockFile'
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3635#changeloghttp://ghc.haskell.org/trac/ghc/ticket/1324
http://ghc.haskell.org/trac/ghc/ticket/1324#1324: threadDelay can't handle long timesThu, 03 May 2007 17:12:56 GMTguest<p>
With (Control.Concurrent.threadDelay :: Int -&gt; IO ()) and the parameter interpreted as microseconds, the longest delay time is some 35 minutes, which I find somewhat short. Of course it's possible to call threadDelay several times to implement longer delays, but I ask whether this is the interface we want to have.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1324#changeloghttp://ghc.haskell.org/trac/ghc/ticket/1548
http://ghc.haskell.org/trac/ghc/ticket/1548#1548: printf bugsWed, 18 Jul 2007 16:57:30 GMTl.mai@…<p>
I think the following are bugs in printf:
</p>
<pre class="wiki">Prelude Text.Printf&gt; printf "%.*f" 2 (1/3) :: String
"*** Exception: Printf.printf: bad formatting char *
(expected: "0.33")
Prelude Text.Printf&gt; printf "%.3s" "foobar" :: String
"foobar"
(expected: "foo")
</pre><p>
This one may not be a bug but it's incompatible with C printf:
</p>
<pre class="wiki">Prelude Text.Printf&gt; printf "%10.5d" 4 :: String
" 4"
(expected: " 00004")
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1548#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2270
http://ghc.haskell.org/trac/ghc/ticket/2270#2270: gcd is specialised only for IntWed, 07 May 2008 23:52:35 GMTdons<p>
We have the general:
</p>
<pre class="wiki">
gcd :: (Integral a) =&gt; a -&gt; a -&gt; 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>
And a specialisation for Int only:
</p>
<pre class="wiki">{-# RULES
"gcd/Int-&gt;Int-&gt;Int" gcd = gcdInt
#-}
gcdInt (I# a) (I# b) = g a b
where g 0# 0# = error "GHC.Base.gcdInt: gcd 0 0 is undefined"
g 0# _ = I# absB
g _ 0# = I# absA
g _ _ = I# (gcdInt# absA absB
</pre><p>
Thanks to the gcdInt# primop.
</p>
<p>
If we use Word here, or other Int types, we get the slow version (which is only 10x slower, surprisingly):
</p>
<pre class="wiki">main = print . sumU
. mapU (gcd 2)
$ enumFromToU 0 (100000000 :: Word)
</pre><p>
Comes out as:
</p>
<pre class="wiki">
time ./henning
150000002
./henning 25.73s user 0.05s system 99% cpu 25.936 total
</pre><p>
Versus:
</p>
<pre class="wiki">
$ time ./henning
150000002
./henning 2.33s user 0.00s system 99% cpu 2.334 tota
</pre><p>
So there are two things we can do here to improve the situation:
</p>
<h2 id="Step1:AddrulesforgettingfromtheotherInttypestogcdInt">Step 1: Add rules for getting from the other Int* types to gcdInt#</h2>
<pre class="wiki">
{-# RULES
"gcd/Int32-&gt;Int32-&gt;Int32" gcd = gcdInt32
#-}
gcdInt32 :: Int32 -&gt; Int32 -&gt; Int32
gcdInt32 x y = fromIntegral ((gcd :: Int -&gt; Int -&gt; Int) (fromIntegral x) (fromIntegral y))
</pre><p>
For example, takes the running time from 28 seconds to 2.4seconds, for:
</p>
<pre class="wiki">
main = print . sumU
. mapU (gcd 2)
$ enumFromToU 0 (100000000 :: Int32)
</pre><h2 id="Step2:optionallyaddagcdWord">Step 2: optionally add a gcdWord#</h2>
<p>
We could then also add a gcdWord# primop,or perhaps just following fromIntegral, and test
for negative first, then conditionally dispatch to gcdInt.
</p>
<p>
What do people think?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2270#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2610
http://ghc.haskell.org/trac/ghc/ticket/2610#2610: File permission-related proposalsThu, 18 Sep 2008 17:28:48 GMTigloo<p>
Once 6.10 is out of the way, we should file some permission-related proposals.
</p>
<p>
<tt>openTempFile</tt> and <tt>openBinaryTempFile</tt> mask the file permissions of the file they create with 0o600. However, we would like to use it for implementing things like <tt>writeFileAtomic</tt>, in which case we want the default file permissions to be used.
</p>
<p>
<tt>System.Directory</tt> has an internal <tt>copyPermissions</tt> function, but it should be exported.
This is not the same as <tt>getPermissions s &gt;&gt;= setPermissions d</tt> as the Permissions type that the latter uses doesn't hold all the permissions info that we want.
</p>
<p>
Even better would be to make the Permissions type abstract, so that it /can/ contain all the info we want. Functions in the unix and Win32 packages would be able to do more with this type than the portable interface.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2610#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2678
http://ghc.haskell.org/trac/ghc/ticket/2678#2678: hLookAhead + hSetBuffering = unsupported operation (Illegal seek)Fri, 10 Oct 2008 02:40:55 GMTigloo<p>
If you compile and run this program, and then press 'a' while it is running:
</p>
<pre class="wiki">module Main (main) where
import System.IO
main :: IO ()
main = do hSetBuffering stdin NoBuffering
hLookAhead stdin &gt;&gt;= print
hSetBuffering stdin LineBuffering
</pre><p>
then you get (amd64/Linux):
</p>
<pre class="wiki">$ ./y
a'a'
y: &lt;stdin&gt;: hSetBuffering: unsupported operation (Illegal seek)
</pre><p>
The docs at
<a href="http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#v%3AhSetBuffering">http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#v%3AhSetBuffering</a>
say what happens when setting a buffer to NoBuffering, but don't give any clue that this can happen when changing to LineBuffering. I don't know if it is the behaviour or the docs that should be changed.
</p>
<p>
Also happens in the 6.10 branch.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2678#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3051
http://ghc.haskell.org/trac/ghc/ticket/3051#3051: Add product/sum/maximum/minimum specialisations for more atomic typesFri, 27 Feb 2009 09:08:00 GMTthorkilnaur<p>
Quoting dons (<a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016707.html"><span class="icon">​</span>http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016707.html</a>):
</p>
<blockquote>
<p>
... product/sum/maximum/minimum
on lists have specialisations for some atomic types (Int, Integer) but
not all (needs a ticket for this too).
</p>
</blockquote>
<p>
So here is that ticket, just to help us remember.
</p>
<p>
Best regards
Thorkil
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3051#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3128
http://ghc.haskell.org/trac/ghc/ticket/3128#3128: hClose leaves file descriptor open if it failsSat, 28 Mar 2009 19:33:18 GMTBaughn<p>
In libraries/base/GHC/Handle.hs, function hClose_help, we attempt to flush the write buffer before closing a handle's underlying FD.
</p>
<p>
If flushing the write buffer fails, for example if this is a network socket that has been closed by the remote host, hClose throws an exception inside flushWriteBufferOnly and the socket is not closed. As a result, the program leaks sockets.
</p>
<p>
The solution is to always close the FD (that is, call hClose_handle_) regardless of errors, but I am not confident of writing correct exception-handling code without the usual abstractions available.
</p>
<p>
Also, inside hClose_handle_, an error is thrown if c_close ever returns -1. It may be practically impossible for this to be caused by EINTR, but is it theoretically impossible?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3128#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3199
http://ghc.haskell.org/trac/ghc/ticket/3199#3199: System.Environment provides no access to argv[0]Tue, 28 Apr 2009 20:33:18 GMTguest<p>
The docs for <tt>getProgName</tt> say:
</p>
<blockquote>
<p>
Computation getProgName returns the name of the program as it was invoked.
</p>
</blockquote>
<blockquote>
<p>
However, this is hard-to-impossible to implement on some non-Unix OSes, so instead, for maximum portability, we just return the leafname of the program as invoked. Even then there are some differences between platforms: on Windows, for example, a program invoked as foo is probably really FOO.EXE, and that is what getProgName will return.
</p>
</blockquote>
<p>
I think the "just return the leafname" part is stupid, because it means there is no way for me to get at C's <tt>argv[0]</tt>. How does mangling <tt>argv[0]</tt> increase portability? It just makes Haskell incompatible with everything else out there. Also, if your platform has <tt>argv[0]</tt>, you might as well return it as-is.
</p>
<p>
Why do I want <tt>argv[0]</tt> at all? Well, the ability to write a drop-in replacement for a C program that does something like <tt>fprintf(stderr, "%s: %s: %s\n", argv[0], filename, strerror(errno))</tt> would be nice (where "drop-in" = character for character the same output). My current project is an IRC bot that can restart itself via <tt>exec()</tt>, preserving state in its command line arguments. However, I usually don't "install" the bot, I just run it from some directory. In this case <tt>argv[0]</tt> would be perfect: if it contains slashes, the bot was run from some directory (and <tt>exec()</tt> will find it there); if it doesn't, the executable was found in the path (and <tt>exec()</tt> will find that too).
</p>
<p>
To summarize: I think the inability to get at argv<a class="missing changeset" title="No changeset 0 in the repository">[0]</a> from Haskell is a bug. If you don't want to change <tt>getProgName</tt>, please consider adding another function (<tt>getNativeProgName</tt>?).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3199#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3200
http://ghc.haskell.org/trac/ghc/ticket/3200#3200: System.Environment.withProgName strips everything before the last slashTue, 28 Apr 2009 20:50:24 GMTguest<p>
The documentation for <tt>withProgName</tt> says:
</p>
<blockquote>
<p>
withProgName name act - while executing action act, have getProgName return name.
</p>
</blockquote>
<p>
However:
</p>
<pre class="wiki">% ghc -e 'System.Environment.withProgName "Hello / World///." System.Environment.getProgName'
"."
</pre><p>
I discovered this while trying to work around bug <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3199" title="bug: System.Environment provides no access to argv[0] (closed: wontfix)">#3199</a> like this:
</p>
<pre class="wiki">main = do
exe &lt;- readSymbolicLink "/proc/self/exe"
withProgName exe main'
...
</pre><p>
So... I need to re-exec my program. Fortunately, there is <tt>argv[0]</tt> containing exactly the information I need. Unfortunately, Haskell doesn't let me access it. Fortunately, Linux provides the full path to my program in a special file and Haskell lets me "fix" the program name at startup. Unfortunately, this functionality is broken: <tt>withProgName</tt> only takes the part after the last slash. Back to square one. :-(
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3200#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3280
http://ghc.haskell.org/trac/ghc/ticket/3280#3280: The order of arguments to the function passed to nubBy got swapped somehowSat, 06 Jun 2009 05:19:29 GMTguest<p>
According to the Report:
</p>
<pre class="wiki"> nubBy :: (a -&gt; a -&gt; Bool) -&gt; [a] -&gt; [a]
nubBy eq [] = []
nubBy eq (x:xs) = x : nubBy eq (filter (\y -&gt; not (eq x y)) xs)
</pre><p>
Hence, we should have that
</p>
<pre class="wiki">nubBy (&lt;) (1:2:[])
= 1 : nubBy (&lt;) (filter (\y -&gt; not (1 &lt; y)) (2:[]))
= 1 : nubBy (&lt;) []
= 1 : []
</pre><p>
However in ghc-6.10.3:
</p>
<pre class="wiki">Prelude Data.List&gt; nubBy (&lt;) [1,2]
[1,2]
</pre><p>
The order of the parameters to the function which is passed to nubBy is *important* since the function might not be an equivalence relation. nubBy is more generally useful for sieving even when the relation is not symmetric. groupBy, for a similar reason, has applications for grouping beyond those provided by equivalence relations, and I think we should be able to rely on its behaviour.
</p>
<p>
Moreover, I contend that the Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list.
</p>
<ul><li>Cale
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3280#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3293
http://ghc.haskell.org/trac/ghc/ticket/3293#3293: Implement shiftLInteger and shiftRIntegerWed, 10 Jun 2009 20:43:10 GMTigloo<p>
Currently <tt>shift</tt> for <tt>Integer</tt> (in <tt>Data.Bits</tt>) is defined in terms of <tt>(*)</tt>, <tt>div</tt> and <tt>^</tt>.
</p>
<p>
Instead, <tt>integer-*</tt> should export <tt>shiftLInteger</tt> and <tt>shiftRInteger</tt>, which can be more efficient.
</p>
<p>
We should do this after the builtin-primop/FFI-imported-primop stuff is worked out, so that we can use a suitable GMP function for it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3293#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3310
http://ghc.haskell.org/trac/ghc/ticket/3310#3310: `show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar`Thu, 18 Jun 2009 23:56:56 GMTenolan<p>
<tt>show BlockedIndefinitely</tt> and <tt>show BlockedOnDeadMVar</tt> should, IMO, evaluate to inequal strings that reflect the difference in cause of the exception. Them being equal is confusing for programmers trying to find the source of their crashes when the exception is printed to console.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3310#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3487
http://ghc.haskell.org/trac/ghc/ticket/3487#3487: Data.ByteString.Lazy.elemIndices returns wrong resultsThu, 03 Sep 2009 13:34:21 GMTnwn<p>
elemIndices for Lazy ByteString returns wrong results occasionally for huge input.
</p>
<pre class="wiki">-- lei.hs
import qualified Data.ByteString.Lazy as L
import Control.Monad
main = do
n &lt;- fmap (length . L.elemIndices 10) L.getContents
putStrLn (show n)
</pre><pre class="wiki">$ ghc --make lei
[1 of 1] Compiling Main ( lei.hs, lei.o )
Linking lei ...
$ yes | head -1000000 | ./lei
1000000
$ yes | head -1000000 | ./lei
999992
$ yes | head -1000000 | ./lei
999960
$ yes | head -1000000 | ./lei
1000000
$ yes | head -1000000 | ./lei
999976
</pre><p>
Without getContents, elemIndices works fine.
</p>
<pre class="wiki">import qualified Data.ByteString.Lazy as L
import System.Environment
main = do
n &lt;- fmap (read . head) getArgs
let cs = L.pack . take (2*n) . cycle $ [48,10]
ps = L.elemIndices 10 cs
print (length ps)
</pre><pre class="wiki">$ ghc --make lei2.hs
[1 of 1] Compiling Main ( lei2.hs, lei2.o )
Linking lei2 ...
$ ./lei2 1000000
1000000
$ ./lei2 1000000
1000000
</pre><p>
So I think there is a problem about bytestring IO.
</p>
<p>
And I heard this isn't reproduced in Windows' command prompt.
</p>
<p>
This ticket is based on <a class="ext-link" href="http://www.sampou.org/cgi-bin/w3ml.cgi/haskell-jp/msg/381"><span class="icon">​</span>a thread of haskell-jp</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3487#changeloghttp://ghc.haskell.org/trac/ghc/ticket/454
http://ghc.haskell.org/trac/ghc/ticket/454#454: hPutBuf doesn't respect LineBufferingTue, 13 Sep 2005 09:44:43 GMTsimonmar<pre class="wiki">On 15 April 2005 02:39, Ian Lynagh wrote:
&gt; If I run this program:
&gt;
&gt; --------------------------------------------------
&gt; import System.Cmd (system)
&gt; import Foreign.C.String (castCharToCChar)
&gt; import Foreign.Marshal.Array (newArray)
&gt; import System.IO (hSetBinaryMode, hPutBuf, stdout,
hSetBuffering,
&gt; BufferMode(..))
&gt;
&gt; main = do hSetBinaryMode stdout True
&gt; hSetBuffering stdout LineBuffering
&gt; p &lt;- newArray (map castCharToCChar "foo\n")
&gt; hPutBuf stdout p 4
&gt; system "sleep 5"
&gt; putStr "bar\n"
&gt; --------------------------------------------------
&gt;
&gt; compiled by GHC then it waits 5 seconds and then
prints foo and bar
&gt; together.
&gt;
&gt; With hugs, foo is printed and then 5 seconds later
bar is printed, as
&gt; I would expect.
True, the implementation doesn't respect LineBuffering
(though it does
respect the other buffering modes, I believe). That's
a bug.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/454#changelog