On 11-03-23 05:31 PM, Ketil Malde wrote:
Any idea why it works in GHCI?
Documentedly, stack limit is 8M, and can be changed by +RTS -K42M (for
example).
Undocumentedly, certain magic numbers given to -K seem to waive the
limit (or set it so high I haven't fathomed).
GHC 6.10.4: 4 to 59
GH
Tsuru Capital has an opening for an intern for three months starting next
month in Tokyo. We are looking for people with moderate experience with
Haskell or another functional programming language. Evidence of work
written in Haskell is a big plus.
More details can be found here. There is a sma
On Thu, Mar 24, 2011 at 4:02 PM, Joshua Ball wrote:
> Never mind. I figured it out on my own. Here's my solution for
> posterity. There's probably a "fix" hiding in there somewhere - notice
> the new type of reduce.
Yep, there is:
> force :: M.Map Key Chain -> M.Map Key [Int]
> force mp = ret wh
Never mind. I figured it out on my own. Here's my solution for
posterity. There's probably a "fix" hiding in there somewhere - notice
the new type of reduce.
module Recursion where
import Data.Map ((!))
import qualified Data.Map as M
import Debug.Trace
newtype Key = Key { unKey :: String }
der
On 03/24/2011 11:30 AM, Erik Hesselink wrote:
I've just tested this, and with GHC 7, cabal chooses QuickCheck 2.4,
whereas with GHC 6.12, it chooses 2.1. If I specify that 6.12 should
choose 2.4 as well, I get the same issue there. This is to be
expected, because I don't see the CPP checks you me
{-
- Hi all,
-
- I'm having trouble tying the recursive knot in one of my programs.
-
- Suppose I have the following data structures and functions:
-}
module Recursion where
import Control.Monad.Fix
import Data.Map ((!))
import qualified Data.Map as M
import Debug.Trace
newtype Key = Key {
On Thu, Mar 24, 2011 at 9:30 AM, Erik Hesselink wrote:
> I've just tested this, and with GHC 7, cabal chooses QuickCheck 2.4,
> whereas with GHC 6.12, it chooses 2.1.
I believe that the behavior you're seeing is because the package
selection is biased by the state of your local package databases
I've just tested this, and with GHC 7, cabal chooses QuickCheck 2.4,
whereas with GHC 6.12, it chooses 2.1. If I specify that 6.12 should
choose 2.4 as well, I get the same issue there. This is to be
expected, because I don't see the CPP checks you mentioned in
Test/QuickCheck/Instances.hs in testp
| class Monoid (GeneratorOf a) => Generable a where
| type GeneratorOf a :: * -> *
| construct :: GeneratorOf a -> a
|
| Now, it seems I need FlexibleInstances to do this when I'm using an
| associated type synonym, but I don't need the flexibility when using a
| multiparameter type class.
Hi folks,
I don't have a GHC 7 environment running yet (it's on my list...) but I
received a bug report pointing me at this build failure:
http://hackage.haskell.org/packages/archive/testpack/2.0.1/logs/failure/ghc-7.0
Among other things, this noted:
Dependency QuickCheck >=2.1.0.3: using Qu
On Thu, Mar 24, 2011 at 9:53 AM, oliver mueller
wrote:
> if anybody knows of a better way please let me know!
I'd recommending trying to fix your "obscure FFI problems" re: the
threaded RTS and go back to using that. Switching concurrency off
altogether is a curious response to dealing with an is
On Thu, Mar 24, 2011 at 1:49 AM, Daniel Díaz wrote:
> Hi, cafe,
>
> all I want is to read the unread portion of a handle, without blocking
> waiting for an EOF or a newline. My first attempt was to try with
> hGetBufNonBlocking from System.IO, and other functions that use it in its
> definition (
after reading in "GHC's implementation of concurrency" and even more
important in the documentation of hWaitForInput it seems clear that my
receiver thread blocks and the sender cannot be executed:
"NOTE for GHC users: unless you use the -threaded flag, hWaitForInput
t where t >= 0 will block all o
Hi, cafe,
all I want is to read the unread portion of a handle, without blocking
waiting for an EOF or a newline. My first attempt was to try with
hGetBufNonBlocking from System.IO, and other functions that use it in
its definition (directly or indirectly). But, unfortunately:
hGetBufNonBloc
14 matches
Mail list logo