Re: [GHC] #5464: Change the way the extra bindings for the generic representation are generated

2011-10-07 Thread GHC
#5464: Change the way the extra bindings for the generic representation are generated -+-- Reporter: dreixel | Owner: dreixel Type: task | Status: new

Re: [GHC] #5464: Change the way the extra bindings for the generic representation are generated

2011-10-07 Thread GHC
#5464: Change the way the extra bindings for the generic representation are generated -+-- Reporter: dreixel | Owner: dreixel Type: task | Status: new

Re: [GHC] #5464: Change the way the extra bindings for the generic representation are generated

2011-10-07 Thread GHC
#5464: Change the way the extra bindings for the generic representation are generated -+-- Reporter: dreixel | Owner: dreixel Type: task | Status: new

Re: [GHC] #5464: Change the way the extra bindings for the generic representation are generated

2011-10-07 Thread GHC
#5464: Change the way the extra bindings for the generic representation are generated -+-- Reporter: dreixel | Owner: dreixel Type: task | Status: new

Re: [GHC] #5464: Change the way the extra bindings for the generic representation are generated

2011-10-07 Thread GHC
#5464: Change the way the extra bindings for the generic representation are generated --+- Reporter: dreixel | Owner: dreixel Type: task | Status: closed Priority:

[GHC] #5534: ghci -fobject-code strangeness

2011-10-07 Thread GHC
#5534: ghci -fobject-code strangeness -+-- Reporter: simonmar |Owner: Type: bug | Status: new Priority: normal|Milestone: 7.4.1

[GHC] #5535: Performance regression vs. 7.2.1

2011-10-07 Thread GHC
#5535: Performance regression vs. 7.2.1 -+-- Reporter: simonmar |Owner: Type: bug | Status: new Priority: highest |Milestone: 7.4.1

Re: [GHC] #5527: mkTopLevEnv: not interpreted

2011-10-07 Thread GHC
#5527: mkTopLevEnv: not interpreted +--- Reporter: cdsmith |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: GHC API

Re: [GHC] #5527: mkTopLevEnv: not interpreted

2011-10-07 Thread GHC
#5527: mkTopLevEnv: not interpreted +--- Reporter: cdsmith |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: GHC API

Re: [GHC] #5234: The parListWHNF optimisation isn't

2011-10-07 Thread GHC
#5234: The parListWHNF optimisation isn't +--- Reporter: duncan | Owner: simonmar Type: bug| Status: closed Priority: high |

Re: [GHC] #5471: Incorrect InterruptibleFFI test

2011-10-07 Thread GHC
#5471: Incorrect InterruptibleFFI test -+-- Reporter: shelarcy |Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: 7.4.1

[GHC] #5536: IO performance regression in 7.2 vs 7.0

2011-10-07 Thread GHC
#5536: IO performance regression in 7.2 vs 7.0 -+-- Reporter: simonmar |Owner: Type: bug | Status: new Priority: high |Milestone:

Re: [GHC] #5503: 32-bit testsuite failures

2011-10-07 Thread GHC
#5503: 32-bit testsuite failures +--- Reporter: daniel.is.fischer | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component:

Re: [GHC] #2897: HsFFI.h is not in the default include path for hsc2hs

2011-10-07 Thread GHC
#2897: HsFFI.h is not in the default include path for hsc2hs ---+ Reporter: cjs | Owner: Type: bug | Status: new Priority: highest |

Re: [GHC] #5504: Inconsistent sizes for struct rlimit

2011-10-07 Thread GHC
#5504: Inconsistent sizes for struct rlimit +--- Reporter: daniel.is.fischer | Owner: Type: bug| Status: closed Priority: normal | Milestone:

Re: [GHC] #2897: HsFFI.h is not in the default include path for hsc2hs

2011-10-07 Thread GHC
#2897: HsFFI.h is not in the default include path for hsc2hs ---+ Reporter: cjs | Owner: Type: bug | Status: new Priority: highest |

Re: [GHC] #5498: Generalized newtype deriving allows creating of instances I can't create by hand

2011-10-07 Thread GHC
#5498: Generalized newtype deriving allows creating of instances I can't create by hand -+-- Reporter: dterei|Owner: Type: bug | Status: new

Re: [GHC] #5505: Program runs faster with profiling than without

2011-10-07 Thread GHC
#5505: Program runs faster with profiling than without -+-- Reporter: simonpj |Owner: simonmar Type: bug | Status: new Priority: high |

[GHC] #5537: ghc doesn't find libffi.so.5 in testsuite

2011-10-07 Thread GHC
#5537: ghc doesn't find libffi.so.5 in testsuite --+- Reporter: daniel.is.fischer | Owner: Type: bug| Status: new Priority: normal |

Re: [GHC] #5368: ghc.exe; panic! (the 'impossible' happened)

2011-10-07 Thread GHC
#5368: ghc.exe; panic! (the 'impossible' happened) +--- Reporter: dmitriev200 |Owner: simonmar Type: bug | Status: new Priority: high |Milestone: 7.4.1

Re: [GHC] #5505: Program runs faster with profiling than without

2011-10-07 Thread GHC
#5505: Program runs faster with profiling than without -+-- Reporter: simonpj |Owner: simonmar Type: bug | Status: new Priority: high |

Re: [GHC] #5537: ghc doesn't find libffi.so.5 in testsuite

2011-10-07 Thread GHC
#5537: ghc doesn't find libffi.so.5 in testsuite --+- Reporter: daniel.is.fischer | Owner: Type: bug| Status: new Priority: normal |

Re: [GHC] #5537: ghc doesn't find libffi.so.5 in testsuite

2011-10-07 Thread GHC
#5537: ghc doesn't find libffi.so.5 in testsuite --+- Reporter: daniel.is.fischer | Owner: Type: bug| Status: new Priority: normal |

Re: [GHC] #4900: DEPENDS pragma

2011-10-07 Thread GHC
#4900: DEPENDS pragma -+-- Reporter: cdsmith |Owner: Type: feature request | Status: new Priority: normal|Milestone: 7.4.1

Re: GHC, Clang XCode 4.2

2011-10-07 Thread David Peixotto
On Oct 6, 2011, at 7:32 AM, Simon Marlow wrote: On 05/10/2011 09:46, austin seipp wrote: There has been recent discussion on the Homebrew bug tracker concerning the upcoming XCode 4.2 release by Apple, which has apparently just gone GM (meaning they're going to make a real release on the

[Haskell] VSTTE 2012 Verification Competition: Change of Dates

2011-10-07 Thread Gudmund Grov
***Note: due to a clash with SEFM 2011, *** *** we have moved the competition to November 8-10 *** VSTTE 2012 Verification Competition --- A software verification competition is organized on behalf of the VSTTE 2012 conference

Re: [Haskell-cafe] Question: Lazy Incremental Evaluation and Haskell?

2011-10-07 Thread David Barbour
Functional Reactive Programming can model this sort of 'change over time' incremental computation, but I doubt you'd get a performance benefit from it unless your operations are considerably more expensive than '+' on numbers. Look into the 'Reactive' library, and Conal Elliott's paper on it

Re: [Haskell-cafe] Question: Lazy Incremental Evaluation and Haskell?

2011-10-07 Thread Sean Leather
Hi Benjamin, My question is, roughly, is there already an existing framework for incremental evaluation in Haskell? We at Utrecht have done some work on this: http://people.cs.uu.nl/andres/Incrementalization/ Simply put, if your computation is a fold/catamorphism, then you can easily take

Re: [Haskell-cafe] Question: Lazy Incremental Evaluation and Haskell?

2011-10-07 Thread Heinrich Apfelmus
David Barbour wrote: Benjamin Redelings wrote: My question is, roughly, is there already an existing framework for incremental evaluation in Haskell? Functional Reactive Programming can model this sort of 'change over time' incremental computation, but I doubt you'd get a performance benefit

[Haskell-cafe] Combining stream and list fusion

2011-10-07 Thread Bas van Dijk
Hello, I'm trying to make the following faster: Data.Vector.Generic.fromList list where 'list' is some expression yielding a list. (For example: map (+1) $ map (*2) [1..100]) Note that Data.Vector.Generic.fromList is defined as: fromList :: Vector v a = [a] - v a {-# INLINE fromList #-}

[Haskell-cafe] Best bit LIST data structure

2011-10-07 Thread Ryan Newton
Hi Cafe, We are lucky to have a plethora of data structures out there. But it does make choosing one off hackage difficult at times. In this case I'm *not* looking for a O(1) access bit vector (Data.Vector.Unboxed seems to be the choice there), but an efficient representation for a list of bits

Re: [Haskell-cafe] Question: Lazy Incremental Evaluation and Haskell?

2011-10-07 Thread David Barbour
On Fri, Oct 7, 2011 at 3:17 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: FRP is somewhat orthogonal to incremental computation because FRP is focusing on expressiveness while incremental computation focuses on performance. You can formulate some incremental algorithms in terms of

[Haskell-cafe] SplitObjs and LLVM

2011-10-07 Thread Mathijs Kwik
Hi all, Is it a known issue that -fllvm doesn't produce split objs? I tried ghc 7.0.3 with llvm 2.8 and ghc 7.2.1 with llvm 2.9. Thanks, Mathijs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org

Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically

2011-10-07 Thread Tom Thorne
I have made a dummy program that seems to exhibit the same GC slowdown behavior, minus the segmentation faults. Compiling with -threaded and running with -N12 I get very bad performance (3x slower than -N1), running with -N12 -qg it runs approximately 3 times faster than -N1. I don't know if I

Re: [Haskell-cafe] Question: Lazy Incremental Evaluation and Haskell?

2011-10-07 Thread Brandon Moore
From: Peter Gammie pete...@gmail.com Oct 6. 2011 6:58 PM Ben, On 07/10/2011, at 8:55 AM, Benjamin Redelings I wrote: My question is, roughly, is there already an existing framework for incremental evaluation in Haskell? Margnus Carlsson did something monadic several years ago.

[Haskell-cafe] Is there a DFA library?

2011-10-07 Thread Alex Rozenshteyn
I couldn't find one on hackage that isn't better described as a RegEx library. I'm looking for things like minimization, completion, etc. kinda like http://www.cis.upenn.edu/~cis639/docs/xfst.html However, I may have just missed it. -- Alex R

Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically

2011-10-07 Thread Oliver Batchelor
I'm not sure if this is at all related, but if I run a small Repa program with more threads than I have cores/CPUs then it gets drastically slower, I have a dual core laptop - and -N2 makes my small program take approximately 0.6 of the time. Increasing to -N4 and we're running about 2x the time,

Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically

2011-10-07 Thread Alexander Kjeldaas
I am guessing that it is slowdown caused by GC needing to co-ordinate with blocked threads. That requires lots of re-scheduling to happen in the kernel. This is a hard problem I think, but also increasingly important as virtualization becomes more important and the number of schedulable cores

Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically

2011-10-07 Thread austin seipp
It's GHC, and partly the OS scheduler in some sense. Oversaturating, i.e. using an -N option your number of logical cores (including hyperthreads) will slow down your program typically. This isn't uncommon, and is well known - GHC's lightweight threads have an M:N threading model, but for good