Re: SIGALRM, SIGVTALRM, and third party libraries

2010-09-08 Thread Simon Marlow
On 06/09/10 19:16, Edward Z. Yang wrote: Excerpts from Simon Marlow's message of Mon Sep 06 05:57:59 -0400 2010: What did you have in mind with respect to portable equivalents of pthread functions? I'm not sure we need to do anything along these lines at all, and I'd much rather we didn't

RE: Type Families and defaults

2010-09-08 Thread Simon Peyton-Jones
Mitar I'm afraid I didn't understand your questions well enough to answer them. But it'd be worth reading http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/other-type-extensions.html#scoped-type-variables | It's not trivial to add, but not really hard either.  Has anyone else been |

Re: Type Families and defaults

2010-09-08 Thread Mitar
Hi! I'm afraid I didn't understand your questions well enough to answer them. My question is, why does this type check: instance Neuron TestNeuron where data LiveNeuron TestNeuron = LiveTestNeuron NeuronId mkLiveNeuron nid = LiveTestNeuron nid getNeuronId (LiveTestNeuron nid) = nid

Re: SIGALRM, SIGVTALRM, and third party libraries

2010-09-08 Thread Edward Z. Yang
Excerpts from Simon Marlow's message of Wed Sep 08 03:40:42 -0400 2010: Maybe. As a first step I think we could just document what happens when a call is interrupted (pthread_cancel() on POSIX, ??? on Windows) and let the user handle it. Is there even a good lowest-common-denominator that

HEAD: Deterioration in ByteString I/O

2010-09-08 Thread Daniel Fischer
Trying out HEAD (specifically, ghc-6.13.20100831-src.tar.bz2 built with 6.12.3) investigating an issue with the text package, I found that I/O of ByteStrings has become significantly slower (on my machine at least: $ uname -a Linux linux-mkk1 2.6.27.48-0.2-pae #1 SMP 2010-07-29 20:06:52 +0200

Re: HEAD: Deterioration in ByteString I/O

2010-09-08 Thread Don Stewart
daniel.is.fischer: Trying out HEAD (specifically, ghc-6.13.20100831-src.tar.bz2 built with 6.12.3) investigating an issue with the text package, I found that I/O of ByteStrings has become significantly slower (on my machine at least: $ uname -a Linux linux-mkk1 2.6.27.48-0.2-pae #1 SMP

Re: HEAD: Deterioration in ByteString I/O

2010-09-08 Thread Daniel Fischer
On Wednesday 08 September 2010 18:10:26, Don Stewart wrote: Can you put your benchmark code somewhere? Boiled down to the bare minimum, module Main (main) where import System.Environment (getArgs) import qualified Data.ByteString.Lazy as L main :: IO () main = do (file : _) - getArgs

RE: HEAD: Deterioration in ByteString I/O

2010-09-08 Thread Simon Peyton-Jones
| ghc-6.12.3: | 89,330,672 bytes allocated in the heap | 15,092 bytes copied during GC | 35,980 bytes maximum residency (1 sample(s)) | 29,556 bytes maximum slop | 2 MB total memory in use (0 MB lost due to fragmentation) | |

Re: HEAD: Deterioration in ByteString I/O

2010-09-08 Thread Don Stewart
simonpj: | ghc-6.12.3: | 89,330,672 bytes allocated in the heap | 15,092 bytes copied during GC | 35,980 bytes maximum residency (1 sample(s)) | 29,556 bytes maximum slop | 2 MB total memory in use (0 MB lost due to

haddock and associated data families

2010-09-08 Thread Christian Höner zu Siederdissen
Hi, haddock seems to produce an error on associated data family decls.: http://hackage.haskell.org/packages/archive/PrimitiveArray/0.0.2.1/logs/failure/ghc-6.12 line 22, where the errors occurs is exactly this one: class PrimArrayOps a b where data PrimArray a b :: *-- ^

Re: haddock and associated data families

2010-09-08 Thread Antoine Latter
CC'ing the maintainer listed on Hackage for haddock On Wed, Sep 8, 2010 at 5:14 PM, Christian Höner zu Siederdissen choe...@tbi.univie.ac.at wrote: Hi, haddock seems to produce an error on associated data family decls.:

Re: HEAD: Deterioration in ByteString I/O

2010-09-08 Thread Daniel Fischer
On Wednesday 08 September 2010 23:55:35, Don Stewart wrote: simonpj: | ghc-6.12.3: | 89,330,672 bytes allocated in the heap | 15,092 bytes copied during GC | 35,980 bytes maximum residency (1 sample(s)) | 29,556 bytes maximum slop |

Re: HEAD: Deterioration in ByteString I/O

2010-09-08 Thread Daniel Fischer
On Thursday 09 September 2010 01:28:04, Daniel Fischer wrote: Maybe the following observation helps: ghc-6.13.20100831 reads lazy ByteStrings in chunks of 8192 bytes. If I understand correctly, that means (since defaultChunkSize = 32760) - bytestring allocates a 32K buffer to be filled and

Re[2]: HEAD: Deterioration in ByteString I/O

2010-09-08 Thread Bulat Ziganshin
Hello Daniel, Thursday, September 9, 2010, 3:28:04 AM, you wrote: - bytestring allocates a 32K buffer to be filled and asks ghc for 32760 bytes in that buffer - ghc asks the OS for 8192 bytes (and usually gets them) btw, we made benchmarking that shown that the most efficient read/write