On 19/02/2011 04:57 PM, Edward Amsden wrote:
But note that with GHC 7.x, the RTS *automatically* chooses the correct
number of threads now. You no longer need to specify this manually (unless
you specifically want to use some other number of threads for some reason).
Is that stated in the change
For what it's worth, you can also use GHC.Conc.Sync.numCapabilities to
find out how many cores are actually being used, if you wanted to check.
(I thought this was also exported from Control.Concurrent, but
apparently not...)
___
Haskell-Cafe mailin
On 16/02/2011 11:09 PM, Max Bolingbroke wrote:
Thinking about it some more, this example is actually quite
interesting because if you *prevent* the list from being floated the
forM gets foldr/build fused into a totally listless optimal loop. It
really does seem like a shame to disable that optim
On Fri, 2011-02-18 at 17:27 +0300, Michael A Baikov wrote:
> I am trying to play with iteratee making parser for squid log files, but
> found that my code do not run in constant space when it tries to process
> compressed log files. So i simplified my code down to this snippet:
>
> import Data.B
I have a streaming network protocol where each message in the stream
is prefixed by a 64-bit message length marker. Lazy ByteStrings seem
to be an elegant way to wrap network communications, so I'm using
them. I have one concern though: how can I prevent my program from
hanging on to the beginnin
On Sun, Feb 20, 2011 at 9:38 AM, tsuraan wrote:
> I have a streaming network protocol where each message in the stream
> is prefixed by a 64-bit message length marker. Lazy ByteStrings seem
> to be an elegant way to wrap network communications, so I'm using
> them. I have one concern though: how
On Sunday 20 February 2011 16:38:17, tsuraan wrote:
> I have a streaming network protocol where each message in the stream
> is prefixed by a 64-bit message length marker. Lazy ByteStrings seem
> to be an elegant way to wrap network communications, so I'm using
> them. I have one concern though:
> No, that need not be. If the compiler sees that it's never referenced
> again, it can be garbage collected (assuming the consumption pattern of msg
> allows that to be garbage collected incrementally).
>
> Try out whether your programme has a space leak by giving it a long input.
> If it has, ask
On Sun, Feb 20, 2011 at 03:38:17PM +, tsuraan wrote:
> lazy <- getContents clientSock
> let (lenBS, rest1) = splitAt 8 lazy
> let length = runGet getWord64be lenBS
> let (msg, rest2) = splitAt (fromIntegral length) rest1
> -- process msg
>
> The program never uses that initial "lazy" again, bu
Hi,
When running Alex -g I get several warning telling me that a bang
pattern is required and that the warning will be an error in GHC 6.14.
It is something along the following lines:
Warning: Bindings containing unlifted types must use an outermost
bang pattern:
{ (base) =
On 20 February 2011 19:56, Mihai Maruseac wrote:
> Hi,
>
> When running Alex -g I get several warning telling me that a bang
> pattern is required and that the warning will be an error in GHC 6.14.
As it happens, that is not an error in GHC 7 (see
http://hackage.haskell.org/trac/ghc/ticket/3278):
On Sun, Feb 20, 2011 at 10:20 PM, Max Bolingbroke
wrote:
> On 20 February 2011 19:56, Mihai Maruseac wrote:
>> Hi,
>>
>> When running Alex -g I get several warning telling me that a bang
>> pattern is required and that the warning will be an error in GHC 6.14.
>
> As it happens, that is not an er
Is the "Embedded domain-specific language HANSEI for probabilistic models
and (nested) inference" described in:
http://okmij.org/ftp/kakuritu/index.html#implementation available in
Haskell? Is there a reason why the author did the package in Ocaml
rather than Haskell?
--
Daryoush
___
Sorry for bringing back an ancient thread but I'd still like to understand
this better.
It is still not obvious to me why typechecking infinite types is so hard. Is
determining type 'equivalence' the hard part? or is that a separate issue?
I wrote a simple infinite type inferer and made an attem
Thanks Oliver!
I haven't had time to look at your bindings very closely, but I do
have a few initial things to think about:
* You're writing your imports by hand. Several other projects used
to do this, and it's a pain in the neck when you have hundreds
of functions that you need
>From: Job Vranish
>
>Sorry for bringing back an ancient thread but I'd still like to understand
>this
>better.
>
>It is still not obvious to me why typechecking infinite types is so hard. Is
>determining type 'equivalence' the hard part? or is that a separate issue?
Typechecking with regular
On Sun, Feb 20, 2011 at 8:16 AM, tsuraan wrote:
> Ok, I'll see if I have any problems. What I'm doing seemed like it
> might be the wrong way to go, so I figured I'd ask about it to see if
> I got any "don't do that" type responses. Sounds like what I'm doing
> is pretty much sane, so I'll see i
17 matches
Mail list logo
