| Using Haskell for this networking app forced me to focus on all the
| issues _but_ the business logic. Type constraints, binary IO and
| serialization, minimizing memory use and fighting laziness, timers,
| tweaking concurrency and setting up message channels, you name it.
That's a
Hello,
On Tue, 27 Dec 2005 16:39:34 +, Chris Kuklewicz wrote:
Happy Holidays,
I was wondering if it this small snippet of code could be altered to
require fewer OPTIONS -fallow-... switches.
Here is a partial solution using only -fglasgow-exts:
module MyShow where
class MyShow t where
I did look into this a little. There are several things going on
* GHC doesn't really expect you to use INLINE and SPECIALISE together.
INLINE says to inline a copy of the function at every call site, which
is the best possible form of specialisation, so SPECIALISE is a bit
redundant if you are
Michael Benfield wrote:
I see here:
http://www.haskell.org/HOpenGL/newAPI/
OpenAL bindings listed as part of the Hierachical Libraries. And when I
download the source to a development snapshot of GHC, there they are. Is
there a way to install this on GHC 6.4?
Alternatively... I can't get
Hello David,
Thursday, December 29, 2005, 3:42:05 AM, you wrote:
stats elems = foldl add_elem Map.empty elems
DR This program has a space leak and runs out of stack space. I'm guessing
DR that I'm being bit here by an unnatural amount of laziness in
DR Map.insertWith
stack overflows AFAIK is
On Thu, Dec 29, 2005 at 11:22:11AM +0300, Bulat Ziganshin wrote:
stack overflows AFAIK is never occur because of laziness, but only
because your recursion is not tail-optimized.
AFAIK, evaluating a thunk in GHC-compiled code does use the stack -
update frames are being put on it.
There is a
Hello,
I haven't followed everything that's happened on the Binary IO
thread, but has anybody else actually tried Joels code? ..
http://wagerlabs.com/timeleak.tgz
I can reproduce the problem (ghc/Linux), but can't explain it. It
seems very strange that friggin about with an otherwise
Thanks for looking, Adrian,
It'd be great if someone was able to find out more about what's going on
here. Bandwidth at GHC HQ is always tight, so the more precisely
someone can pinpoint what's happening, the faster we can fix it. Joel
has done a lot by making a repro case. Maybe others can
Adrian,
There's no mistery here.
Threads take a while to unpickle the large server info packet when
the gang up on it all together. By adding the MVar you are basically
installing a door in front of the packet and only letting one thread
come through.
The end result is that you are
David Roundy wrote:
stats elems = foldl add_elem Map.empty elems
add_elem m x = Map.insertWith (+) x 1 m
main = print $ stats $ take 100 $ repeat 1
This program has a space leak and runs out of stack space. I'm guessing
that I'm being bit here by an unnatural amount of laziness in
On Thu, Dec 29, 2005 at 01:02:45PM +, Adrian Hey wrote:
I haven't followed everything that's happened on the Binary IO
thread, but has anybody else actually tried Joels code? ..
http://wagerlabs.com/timeleak.tgz
I have and I am puzzled too.
I can reproduce the problem (ghc/Linux), but
On Thu, Dec 29, 2005 at 01:20:41PM +, Joel Reymont wrote:
Why does it take a fraction of a second for 1 thread to unpickle and
several seconds per thread for several threads to do it at the same
time? I think this is where the mistery lies.
Have you considered any of this:
- too big
On Thu, Dec 29, 2005 at 01:42:29PM +0100, Christian Maeder wrote:
David Roundy wrote:
stats elems = foldl add_elem Map.empty elems
add_elem m x = Map.insertWith (+) x 1 m
main = print $ stats $ take 100 $ repeat 1
This program has a space leak and runs out of stack space. I'm
Bulat Ziganshin writes:
your BlockIO library is great, but it's usage is limited
to very specific sutuations - when we can save pass state
between processing of individual bytes
In my experience, any other approach to I/O is slow. If you
don't have an explicit state between processing of
On Thu, Dec 29, 2005 at 04:24:02PM +0100, Jean-Philippe Bernardy wrote:
On 12/29/05, David Roundy [EMAIL PROTECTED] wrote:
On Thu, Dec 29, 2005 at 01:42:29PM +0100, Christian Maeder wrote:
David Roundy wrote:
stats elems = foldl add_elem Map.empty elems
add_elem m x = Map.insertWith
Hi,
I am trying to read _Arrows, Robots, and Functional Reactive
Programming_ by Hudak, et al.
http://www.haskell.org/yampa/AFPLectureNotes.pdf
In section 2.1 there are a number of equations of the form:
g’ :: SF A C
g’ = arr g
= arr f1 arr f2
and
i’ :: SF (A,C) (B,D)
i’ = arr i
On Dec 29, 2005, at 11:26 AM, David F. Place wrote:
Hi,
I am trying to read _Arrows, Robots, and Functional Reactive
Programming_ by Hudak, et al.
http://www.haskell.org/yampa/AFPLectureNotes.pdf
In section 2.1 there are a number of equations of the form:
g’ :: SF A C
g’ = arr g
=
On Thu, Dec 29, 2005 at 03:34:10PM -0500, Cale Gibbard wrote:
The issue with it taking too long seems to basically be as Joel said,
only one of the threads can take that MVar at a time. Even if the time
that it's taken is fairly short, if one is running faster than the
others, it tries to take
Albert Lai writes:
For almost a decade, most (I dare claim even all) Pascal
and C compilers were three-pass or two-pass. It means
perhaps the compiler reads the input two or three times
[...], or perhaps the compiler reads the input once,
produces an intermediate form and saves it to
On Thu, 2005-12-29 at 15:56 -0500, Albert Lai wrote:
. . .
one-pass fast method, since for almost a decade no one did it. Most
of us had to wait until someone figured it out and then we had Turbo
Judging from comments by U. Ammann [1],[2], part of the original Pascal
implementation team at
Laziness and strictness are both important depending on the situation.
I'd recommend keeping both variants around. Having to wrap values in
an extra data type just to keep laziness sort of defeats the point of
Haskell being lazy in the first place. It also makes it somewhat
awkward to use in the
Also, if you are trying to display a line that looks like
insert 5
or
consume 6
then consider using
putStrLn (insert ++ show r)
putStrLn (consume ++ show r)
instead of
print (insert ++ show r)
print
I particularly like OCaml's provision of subtyping. As a member of
the ML family, it's module system is also quite formidable. Of course
the imperative constructs are also pretty convenient when you just
want to be quirky. But I miss the monad do-notation.
Here's a version that provides clean output with no delays. It uses a
single-entry mailbox (the TMVar output) to ensure the processing
doesn't run too far ahead of the log.
module Test where
import System.Random
import Control.Concurrent
import Control.Concurrent.STM
test :: IO ()
test =
do
On Dec 23, 2005, at 11:53, Arjen wrote:
On Fri, 23 Dec 2005, Joel Reymont wrote:
Folks,
I have been looking at the code for the Arrows for invertible
programming paper (http://www.cs.ru.nl/A.vanWeelden/bi-arrows/) and
I have a question about syntax. ghci surely does not like it.
I've
On Fri, Dec 16, 2005 at 07:55:50AM -0800, Scherrer, Chad wrote:
From: S Koray Can [mailto:[EMAIL PROTECTED]
Why not do this: name none of those modules Main.hs, and have an empty
module Main.hs with only import MainDeJour and main =
MainDeJour.main so you can just edit just that file.
From: Isaac Gouy [EMAIL PROTECTED]
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Re: Haskell Speed
Date: Thu, 29 Dec 2005 13:00:15 -0800 (PST)
--- Isaac Gouy [EMAIL PROTECTED] wrote:
We'll be happy to also show a Haskell program that
uses Data.HashTable - first, someone needs to
On Dec 29, 2005, at 7:44 PM, Branimir Maksimovic wrote:
To comment some observation on this program.
Most of the pressure now is on Data.HashTable.
I've susspected such large memory usage on substring from array
conversions,
so mad version with data MyString = MakeMyStrinf { buf :: Ptr Char,
Yes, good point. I suppose there's really no need to re-declare main once it's
been imported. Thanks!
-Original Message-
From: Remi Turk [mailto:[EMAIL PROTECTED]
Sent: Thu 12/29/2005 4:34 PM
To: Scherrer, Chad
Cc: S Koray Can; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] RE:
On Thu, Dec 29, 2005 at 10:36:37PM +0100, Tomasz Zielonka wrote:
On Thu, Dec 29, 2005 at 03:34:10PM -0500, Cale Gibbard wrote:
The issue with it taking too long seems to basically be as Joel said,
only one of the threads can take that MVar at a time. Even if the time
that it's taken is
30 matches
Mail list logo
