Re: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure ---+ Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonmar): In principle this is a good change, however I don't agree with the changes in semantics of `hGetBufNonBlocking` and `hGetBufSome`. As it stands right now, `hGetBuf`, `hGetBufNonBlocking` and `hGetBufSome` will all read the same amount of data, if the data is available without blocking. But in your version (unless I've misread it), `hGetBufNonBlocking` will read at most a buffer of data, which seems to me to be an abstraction violation - the buffer size is supposed to be invisible to callers of the `hGetBuf` family. Why make this change? It should be possible to loop and read more data in the same way as `hGetBuf`. The only other minor quibble I have with this patch is that the documentation for `readBuffered` and friends could be improved - it isn't clear what the purpose of the buffer argument is (without reading the code). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4144#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7534: allocateRegsAndSpill: Cannot read from uninitialized register
#7534: allocateRegsAndSpill: Cannot read from uninitialized register --+- Reporter: erikd | Owner: simonmar Type: bug| Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Linux Architecture: powerpc64 | Failure: Building GHC failed Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Comment(by simonmar): So the background is that this panic used to be commented out, but I enabled it recently because it makes debugging much easier (with the panic commented out, the compiler will happily generate completely bogus code that will crash at runtime). However, it adds another invariant, as mentioned in the comment: all register must be written before they are read (not an unreasonable assumption, I'm sure you'll agree) I presume this invariant is being violated somewhere. To debug it you'll need to use `-ddump-cmm` and find out where the bogus code comes from. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7534#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7400: Strange closure type 17 internal error
#7400: Strange closure type 17 internal error -+-- Reporter: ropoctl | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.6.2 Component: Runtime System |Version: 7.4.2 Resolution: invalid | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by igloo): * status: infoneeded = closed * resolution: = invalid Comment: No response from submitter, so closing -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7400#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
#7436: Derived Foldable and Traversable instances become extremely inefficient
due
to eta-expansion
-+--
Reporter: shachaf | Owner:
Type: bug | Status: patch
Priority: normal| Milestone:
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by twanvl@…):
commit 49ca2a37bef18aa57235ff1dbbf1cc0434979b1e
{{{
Author: Twan van Laarhoven twa...@gmail.com
Date: Fri Nov 23 15:03:45 2012 +0100
Changed deriving of Functor, Foldable, Traversable to fix #7436. Added
foldMap to derived Foldable instance.
The derived instances will no longer eta-expand the function. I.e.
instead of
fmap f (Foo a) = Foo (fmap (\x - f x) a)
we now derive
fmap f (Foo a) = Foo (fmap f a)
Some superflous lambdas are generated as a result. For example
data X a = X (a,a)
fmap f (X x) = (\y - case y of (a,b) - (f a, f b)) x
The optimizer should be able to simplify this code, as it is just beta
reduction.
The derived Foldable instance now includes foldMap in addition to
foldr.
compiler/prelude/PrelNames.lhs|9 ++-
compiler/typecheck/TcGenDeriv.lhs | 178
++---
2 files changed, 114 insertions(+), 73 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7436#comment:16
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7436: Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion
#7436: Derived Foldable and Traversable instances become extremely inefficient
due
to eta-expansion
--+-
Reporter: shachaf | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler |Version: 7.6.1
Resolution: fixed| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: perf/should_runt/T7436 | Blockedby:
Blocking: |Related:
--+-
Changes (by simonpj):
* status: patch = closed
* testcase: = perf/should_runt/T7436
* resolution: = fixed
Comment:
Also:
{{{
commit 3d51f271e6819c52508956f2426c4c19dec0b2fb
Author: Twan van Laarhoven twa...@gmail.com
Date: Thu Jan 3 16:24:42 2013 +0100
Added note explaining the lambdas generated by functor deriving code,
and how it compares to the old deriving code which used eta expansion.
}}}
Thanks for the patches!
I added a test in `perf/should_run`. Interestingly the massive difference
is run-time, not in allocation or residency.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7436#comment:17
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7552: ~/.haskeline does nothing in ghci
#7552: ~/.haskeline does nothing in ghci ---+ Reporter: beroal |Owner: Type: bug | Status: closed Priority: normal |Component: GHCi Version: 7.6.1 | Resolution: worksforme Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Other Blockedby: | Blocking: Related: | ---+ Changes (by judahj): * status: new = closed * resolution: = worksforme Comment: `maxHistorySize` takes a `Maybe Int` instead of an `Int`; see the docs for more details: http://trac.haskell.org/haskeline/wiki/UserPrefs Replacing the first line with `maxHistorySize: Just 1` should fix your issue. If not, please reopen this ticket. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7552#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7281: GHC 7.4.2 build fails on Fedora17
#7281: GHC 7.4.2 build fails on Fedora17 --+- Reporter: PaulJohnson| Owner: judah.jacobson@… Type: bug| Status: new Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.4.2 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Building GHC failed Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Comment(by judahj): Replying to [comment:7 igloo]: I've applied this change as 6dde36fa0c347dbbb92affe932c5c79d030867db in GHC's 7.6 branch. Judah, could you apply it in the terminfo main repo please? Then I'll pull it into GHC HEAD. Done, thanks; apologies for the delay. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7281#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4211: LLVM: Stack alignment on OSX
#4211: LLVM: Stack alignment on OSX
--+-
Reporter: dterei | Owner: dterei
Type: task | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler (LLVM) |Version: 6.13
Resolution: | Keywords:
Os: MacOS X | Architecture: x86
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by simonmar):
* status: infoneeded = new
Comment:
I'm slightly unhappy about the solution to this ticket. Since
a9ce36118f0de3aeb427792f8f2c5ae097c94d3f we now align the stack to 16+8
bytes on x86_64, which means that virtually every foreign call now looks
like
{{{
subq $8,%rsp
movl $0,%eax
call foo
addq $8,%rsp
}}}
since most calls on x86_64 pass arguments in registers, the 8 byte
adjustment is to keep the alignment constraint after the return address is
pushed. (The assignment to `%eax` is to keep the ABI happy just in case
the function we're calling is varargs, which is a separate issue).
Now I understand the reason this was done, but I hate having to emit those
two extra instructions around every call. I just wanted to record my
dissatisfaction in this ticket in case it inspires someone to find a
better solution :-)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4211#comment:27
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7498: panic : Register allocator: out of stack slots (need 147)
#7498: panic : Register allocator: out of stack slots (need 147)
--+-
Reporter: erikd| Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.8.1
Component: Compiler |Version: 7.7
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: powerpc
Failure: Building GHC failed | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by marlowsd@…):
commit 03d360f289a1c7e93fedf8cfa274cbe5929cd32c
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Mon Jan 7 12:26:29 2013 +
Fix bugs in allocMoreStack (#7498, #7510)
There were four bugs here. Clearly I didn't test this enough to
expose the bugs - it appeared to work on x86/Linux, but completely by
accident it seems.
1. the delta was wrong by a factor of the slot size (as noted on
#7498)
2. we weren't correctly aligning the stack pointer (sp needs to be
16-byte aligned on x86/x86_64)
3. we were doing the adjustment multiple times in the case of a block
that was both a return point and a local branch target. To fix this I
had to add new shim blocks to adjust the stack pointer, and retarget
the original branches. See comment for details.
4. we were doing the adjustment for CALL instructions, which is
unnecessary and wrong; only JMPs should be preceded by a stack
adjustment.
(Someone with a PPC box will need to update the PPC version of
allocMoreStack to fix the above bugs, using the x86 version as a
guide.)
compiler/nativeGen/AsmCodeGen.lhs | 10 ++--
compiler/nativeGen/PPC/Instr.hs |7 +-
compiler/nativeGen/X86/Instr.hs | 124
+++--
3 files changed, 99 insertions(+), 42 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7498#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.8.1
Component: Compiler | Version: 7.6.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by marlowsd@…):
commit 03d360f289a1c7e93fedf8cfa274cbe5929cd32c
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Mon Jan 7 12:26:29 2013 +
Fix bugs in allocMoreStack (#7498, #7510)
There were four bugs here. Clearly I didn't test this enough to
expose the bugs - it appeared to work on x86/Linux, but completely by
accident it seems.
1. the delta was wrong by a factor of the slot size (as noted on
#7498)
2. we weren't correctly aligning the stack pointer (sp needs to be
16-byte aligned on x86/x86_64)
3. we were doing the adjustment multiple times in the case of a block
that was both a return point and a local branch target. To fix this I
had to add new shim blocks to adjust the stack pointer, and retarget
the original branches. See comment for details.
4. we were doing the adjustment for CALL instructions, which is
unnecessary and wrong; only JMPs should be preceded by a stack
adjustment.
(Someone with a PPC box will need to update the PPC version of
allocMoreStack to fix the above bugs, using the x86 version as a
guide.)
compiler/nativeGen/AsmCodeGen.lhs | 10 ++--
compiler/nativeGen/PPC/Instr.hs |7 +-
compiler/nativeGen/X86/Instr.hs | 124
+++--
3 files changed, 99 insertions(+), 42 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#comment:13
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build -+-- Reporter: simonpj | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Could someone on Windows please test with this patch and close the ticket if all is well? Thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure ---+ Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by joeyadams): Thanks for the review. As it stands right now, hGetBuf, hGetBufNonBlocking and hGetBufSome will all read the same amount of data, if the data is available without blocking. I don't think this is the case anymore; see #5843 and commit [https://github.com/ghc/packages- base/commit/370fc0b455f6a03283fbd5c0baa5d08d9115379d 370fc0b]. The issue is that some devices don't support non-blocking I/O (e.g. file handles on Windows). Here's the problematic sequence: * Call `hWaitForInput`. It returns `True` when the buffer is not empty. * Call `hGetBufSome`, which we expect will not block. It first reads bytes from the buffer, then tries to do a non-blocking read. Since the non-blocking IO methods block on Windows, `hGetBufSome` blocks, even after it has read some data. So here are some of our options: * Change semantics of `hGetBufSome` so that it will only block if there is no input. However, there is no guarantee that `hGetBufSome` will return all immediately available bytes. * On Windows, simulate nonblocking and IODevice.ready by continuously issuing reads in a forked thread to a buffer, and having I/O functions read from that buffer. * Deprecate `hGetBufNonBlocking`, `hPutBufNonBlocking`, `hWaitForInput`, and the non-blocking `RawIO` and `BufferedIO` methods. Come up with an alternative design that does not require the system to support non- blocking operation. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4144#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure ---+ Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by simonmar): Ok, I see that `hGetBufSome` already has the behaviour that I claimed is erroneous. That's sad. I'd really like to declare this to be a bug in the Windows implementation of Handles, but perhaps that's impractical. I think it might be possible to implement non-blocking I/O on Windows, but you have to do it differently for every type of Handle (console, socket, com port etc.). We do have a working implementation of `hWaitForInput` (see `libraries/base/cbits/inputReady.c`) but it's horrible. Maybe deprecating the non-blocking APIs is the right way, since we are providing the ability to do asynchronous I/O using threads, and that's much nicer. But before we do that, we should look at how people are using these APIs. The only user of `hGetBufSome` that I know of, lazy bytestring, works just fine with the read a random amount of data semantics. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4144#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5391: Better deriving for Typeable
#5391: Better deriving for Typeable -+-- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty:|Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by aavogt): * cc: vogt.adam@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5391#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak +--- Reporter: glguy| Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.1| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: |Related: +--- module Main where import qualified Data.ByteString as B import Data.Word (Word8) -- works fast without optimizations -- with optimizations this has a space leak -- seems related to fold/build fusion in foldr/unpack main :: IO () main = do let b = B.replicate 1 1 print $ B.length b print $ example1 b -- fast print $ example2 b -- slow search :: [Word8] - Bool search [] = False search (x:xs) = x == 1 || search xs example1, example2 :: B.ByteString - Bool example1 = search . B.unpack example2 = foldr (\x xs - x == 1 || xs) False . B.unpack -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak
+---
Reporter: glguy| Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 7.6.1| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Blockedby:
Blocking: |Related:
+---
Comment(by glguy):
{{{
module Main where
import qualified Data.ByteString as B
import Data.Word (Word8)
-- works fast without optimizations
-- with optimizations this has a space leak
-- seems related to fold/build fusion in foldr/unpack
main :: IO ()
main = do
let b = B.replicate 1 1
print $ B.length b
print $ example1 b -- fast
print $ example2 b -- slow
search :: [Word8] - Bool
search [] = False
search (x:xs) = x == 1 || search xs
example1, example2 :: B.ByteString - Bool
example1 = search . B.unpack
example2 = foldr (\x xs - x == 1 || xs) False . B.unpack
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak
+---
Reporter: glguy| Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 7.6.1| Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Blockedby:
Blocking: |Related:
+---
Changes (by shachaf):
* cc: shachaf@… (added)
Comment:
The issue is
[http://hackage.haskell.org/packages/archive/bytestring/0.10.2.0/doc/html/src
/Data-ByteString.html#unpackFoldr here]:
{{{
unpack ps = build (unpackFoldr ps)
{-# INLINE unpack #-}
--
-- Have unpack fuse with good list consumers
--
-- critical this isn't strict in the acc
-- as it will break in the presence of list fusion. this is a known
-- issue with seq and build/foldr rewrite rules, which rely on lazy
-- demanding to avoid bottoms in the list.
--
unpackFoldr :: ByteString - (Word8 - a - a) - a - a
unpackFoldr (PS fp off len) f ch = withPtr fp $ \p - do
let loop q n_ | q `seq` n `seq` False = undefined -- n.b.
loop _ (-1) acc = return acc
loop q nacc = do
a - peekByteOff q n
loop q (n-1) (a `f` acc)
loop (p `plusPtr` off) (len-1) ch
{-# INLINE [0] unpackFoldr #-}
{-# RULES
ByteString unpack-list [1] forall p .
unpackFoldr p (:) [] = unpackBytes p
}}}
When we use `foldr`, `foldr/build` fusion turns the whole expression into
an application of `unpackFoldr`, which is tail recursive and therefore not
sufficiently lazy -- but also not strict in the accumulator, so it builds
up a big thunk. In `example1`, fusion doesn't happen, so the fold happens
over `unpackBytes` instead, which generates list in small chunks that can
be processed lazily.
This looks like a `bytestring` bug to me.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7556: build/fold causes with ByteString unpack causes huge memory leak
#7556: build/fold causes with ByteString unpack causes huge memory leak --+- Reporter: glguy | Owner: duncan Type: bug| Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by igloo): * owner: = duncan * difficulty: = Unknown * component: libraries/base = libraries (other) * milestone: = 7.8.1 Comment: Thanks for the diagnosis. Duncan, could you take a look please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7556#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure ---+ Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base|Version: 7.6.1 Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Comment(by joeyadams): For Windows, couldn't we implement non-blocking I/O correctly by first calling the `inputReady.c` function? That is, change `readRawBufferPtrNoBlock` and `writeRawBufferPtrNoBlock` to first call `fdReady` to make sure the operation won't block before proceeding. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4144#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7510: Immediate seg-fault on 32-bit windows build
#7510: Immediate seg-fault on 32-bit windows build ---+ Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler |Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Looks good here, thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7510#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4900: DEPENDS pragma
#4900: DEPENDS pragma ---+ Reporter: cdsmith | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.2 Component: Compiler |Version: Resolution:| Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: TH_Depends| Blockedby: Blocking:|Related: ---+ Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4900#comment:59 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
