Yes, they do
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joel
| Reymont
| Sent: 14 December 2005 20:39
| To: Tomasz Zielonka
| Cc: Simon Marlow; Haskell-Cafe Cafe
| Subject: Re: [Haskell-cafe] Top-level TVars
|
|
| On Wed, Dec 14, 2005 at
Did you read the paper Extending the Haskell Foreign Function Interface
with Concurrency, described in the GHC Wiki page about concurrency?
It'd be a good start
http://hackage.haskell.org/trac/ghc/wiki/GhcConcurrency
Please do improve it.
Simon
| -Original Message-
| From: [EMAIL
On 14 December 2005 20:39, Joel Reymont wrote:
On Wed, Dec 14, 2005 at 02:17:17PM -, Simon Marlow wrote:
Suppose you create two top-level IORefs with the same type, like
this:
var1 = unsafePerformIO $ newIORef 0
var2 = unsafePerformIO $ newIORef 0
GHC's CSE optimisation will
On 14 December 2005 18:04, Bulat Ziganshin wrote:
Hello Simon,
Wednesday, December 14, 2005, 7:39:43 PM, you wrote:
Do other Haskell threads get blocked during an FFI call?
| safeunsafe
--+
-threaded| NO YES
no -threaded | YES
Well, my understanding is that once I do a takeMVar I must do a
putMVar under any circumstances. This is why I was blocking checkTimers.
On Dec 15, 2005, at 12:08 AM, Einar Karttunen wrote:
Is there a reason you need block for checkTimers?
What you certainly want to do is ignore exceptions
On Thu, Dec 15, 2005 at 09:32:38AM +, Joel Reymont wrote:
Well, my understanding is that once I do a takeMVar I must do a
putMVar under any circumstances. This is why I was blocking checkTimers.
Perhaps you could use modifyMVar:
On Dec 15, 2005, at 12:08 AM, Einar Karttunen wrote:
timeout = 500 -- 1 second
Is that correct?
I think so. threadDelay takes microseconds.
Here is a nice trick for you:
Thanks!
--- The filter expression is kind of long...
stopTimer :: String - IO ()
stopTimer name =
block $
Here are statistics that I gathered. I'm almost done modifying the
program to use 1 timer thread instead of 1 per bot as well as writing
to the socket from the writer thread. This should reduce the number
of threads from 6k (2k x 3) to 2k plus change.
It appears that +RTS -k3k does make a
After a chat with Einar on #haskell I realized that I would have,
say, 4k expiring timers and maybe 12k timers that are started and
then killed. That would make a 16k element map on which 3/4 of the
operations are O(n=16k) (Einar).
I need a better abstraction I guess. I also need to be
One idea would be to index the timer on ThreadId and name and stick
Nothing into the timer action once the timer has been fired/stopped.
Since timers are restarted with the same name quite often this would
just keep one relatively big map in memory. The additional ThreadId
would help
Does anyone have priority queue Haskell code that they would be
willing to share or point me to?
Thanks, Joel
--
http://wagerlabs.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On Thu, Dec 15, 2005 at 10:46:55AM +, Joel Reymont wrote:
One idea would be to index the timer on ThreadId and name and stick
Nothing into the timer action once the timer has been fired/stopped.
Since timers are restarted with the same name quite often this would
just keep one
Here's the latest and greatest version put together with Einar's help.
The seconds portion of ClockTime and a counter are used as the key
now and the counter wraps around. This would make two distinct timers
even if there expiration times were the same.
{-# OPTIONS_GHC -fglasgow-exts
Very cool! :)
[EMAIL PROTECTED] wrote:
Stefan Monnier wrote:
I expected at first you were doing some funky type class molestation
so you can use djinn in your code and let Haskell fill it in.
That has already been done:
De-typechecker: converting from a type to a term
On Thursday 15 December 2005 11:50, Joel Reymont wrote:
Does anyone have priority queue Haskell code that they would be
willing to share or point me to?
In fact I have one. It is based on 2-3 finger trees as described in a
paper by Ralf Hinze. it is even better because it is a ordered sequence
I would appreciate it, thank you Ben!
Is this the paper?
http://www.informatik.uni-bonn.de/ ~ralf/publications/UU-CS-2001-09.pdf
On Dec 15, 2005, at 12:26 PM, Benjamin Franksen wrote:
I can send you the sources (today, evening, can't access it at work).
--
http://wagerlabs.com/
On 12/15/05, Joel Reymont [EMAIL PROTECTED] wrote:
Does anyone have priority queue Haskell code that they would be
willing to share or point me to?
Thanks, Joel
Here's one I wrote some time ago:
http://www.dtek.chalmers.se/~sylvan/PriorityQueue/
It's implemented as skewed binomial
On 12/14/05, Simon Marlow [EMAIL PROTECTED] wrote:
On 13 December 2005 14:52, Jan-Willem Maessen wrote:
On Dec 13, 2005, at 8:46 AM, Simon Marlow wrote:
[In response to another plea for TArrays]
In the past I have used arrays of TVars, as Thomasz suggested. It
would indeed be better
On 15 December 2005 13:17, Sebastian Sylvan wrote:
Anyway, the main gist of my original post was that TArrays should be
in the libraries, so that I can safely use it without having to send
along my own implementation each time (and potentially colliding with
someone else's implementation down
On Thu, Dec 15, 2005 at 02:17:18PM +0100, Sebastian Sylvan wrote:
Wouldn't there be a speedup to do both writes and waiting at the array
level, BUT annotated with an index?
I strongly vote to leave STM as it is, and implement TArray as a
library on top of it. STM implementation is probably
On 15 December 2005 10:21, Joel Reymont wrote:
Here are statistics that I gathered. I'm almost done modifying the
program to use 1 timer thread instead of 1 per bot as well as writing
to the socket from the writer thread. This should reduce the number
of threads from 6k (2k x 3) to 2k plus
On 15 December 2005 10:21, Joel Reymont wrote:
Here are statistics that I gathered. I'm almost done modifying the
program to use 1 timer thread instead of 1 per bot as well as writing
to the socket from the writer thread. This should reduce the number
of threads from 6k (2k x 3) to 2k plus
On Dec 15, 2005, at 2:02 PM, Simon Marlow wrote:
The statistics are phys/VM, CPU usage in % and #packets/transfer
speed
Total: 1345, Lobby: 1326, Failed: 0, 102/184, 50%, 90/8kb
Total: 1395, Lobby: 1367, Failed: 2
Total: 1421, Lobby: 1394, Failed: 4
Total: 1490, Lobby:
On 12/15/05, Simon Marlow [EMAIL PROTECTED] wrote:
On 15 December 2005 13:17, Sebastian Sylvan wrote:
Anyway, the main gist of my original post was that TArrays should be
in the libraries, so that I can safely use it without having to send
along my own implementation each time (and
On Dec 15, 2005, at 2:02 PM, Simon Marlow wrote:
Hmm, your machine is spending 50% of its time doing nothing, and the
network traffic is very low. I wouldn't expect 2k connections to pose
any problem at all, so further investigation is definitely required.
With 2k connections the overhead of
Folks,
I'm collecting examples of QuickCheck arbitrary/co-arbitrary
definitions, the more complex the better. Please point me to any or
send them if you are willing to!
Also, is there a cood explanation of co-arbitrary someplace?
Thanks, Joel
--
http://wagerlabs.com/
Something about the way module names are specified in a file seems
really strange to me. When I first started learning Haskell (I had used
OCaml previously), I tried things like
module Main where
import A
import B
main = A.f B.f
module A where
f = ...
module B where
f =
This is what I got for BM. Performance dissapoints as BM is really
suited for indexed strings like arrays.It mainly operates on indexes.
This is simple BM, as I didn't want to go
for more complex variant,becauses takes and drops and recalculation of next
position
is too pricey for non indexed
Simon,
I could not find the paper at the link below but it can be found here:
http://www.haskell.org/~simonmar/papers/conc-ffi.pdf
The paper does not explain the differences I'm seeing between runs of
my program linked with the threaded and non-threaded runtimes. I get
crashes with the
Am Donnerstag, 15. Dezember 2005 02:39 schrieben Sie:
From: Branimir Maksimovic [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: Haskell-Cafe@haskell.org
Subject: Re: [Haskell-cafe] Substring replacements
Date: Thu, 15 Dec 2005 00:55:02 +
From: Daniel Fischer [EMAIL PROTECTED]
To:
Hello Joel,
Thursday, December 15, 2005, 5:13:17 PM, you wrote:
The statistics are phys/VM, CPU usage in % and #packets/transfer
speed
Total: 1345, Lobby: 1326, Failed: 0, 102/184, 50%, 90/8kb
Total: 1395, Lobby: 1367, Failed: 2
Total: 1421, Lobby: 1394, Failed: 4
Total:
Hello Tomasz,
Wednesday, December 14, 2005, 10:48:43 PM, you wrote:
TZ You don't have to check every few seconds. You can determine
TZ exactly how much you have to sleep - just check the timeout/event with
TZ the lowest ClockTime.
this scenario don't count that we can receive new request while
joelr1:
Folks,
I'm collecting examples of QuickCheck arbitrary/co-arbitrary
definitions, the more complex the better. Please point me to any or
send them if you are willing to!
Also, is there a cood explanation of co-arbitrary someplace?
Check the QuickCheck paper for the definition
Bulat,
On Dec 14, 2005, at 9:00 PM, Bulat Ziganshin wrote:
TZ You don't have to check every few seconds. You can determine
TZ exactly how much you have to sleep - just check the timeout/
event with
TZ the lowest ClockTime.
this scenario don't count that we can receive new request while
On Wed, Dec 14, 2005 at 04:39:43PM -, Simon Marlow wrote:
Do other Haskell threads get blocked during an FFI call?
| safeunsafe
--+
-threaded| NO YES
no -threaded | YES YES
this is part of the reason I'd like to see a
On Thu, Dec 15, 2005 at 02:02:02PM -, Simon Marlow wrote:
With 2k connections the overhead of select() is going to start to be a
problem. You would notice the system time going up. -threaded may help
with this, because it calls select() less often.
we should be using /dev/poll on systems
From: Daniel Fischer [EMAIL PROTECTED]
To: Branimir Maksimovic [EMAIL PROTECTED]
CC: Haskell-Cafe@haskell.org
Subject: Re: [Haskell-cafe] Substring replacements
Date: Thu, 15 Dec 2005 21:07:11 +0100
Am Donnerstag, 15. Dezember 2005 02:39 schrieben Sie:
From: Branimir Maksimovic [EMAIL
On 15.12 17:14, John Meacham wrote:
On Thu, Dec 15, 2005 at 02:02:02PM -, Simon Marlow wrote:
With 2k connections the overhead of select() is going to start to be a
problem. You would notice the system time going up. -threaded may help
with this, because it calls select() less often.
Scherrer, Chad [EMAIL PROTECTED] writes:
module Main where
module A where
module B where
in a single file. This example is straight from chapter 5 of the Report,
and no mention is made (that I could find) about modules needing to be
in separate files. But this won't load in ghci!
Einar Karttunen ekarttun@cs.helsinki.fi writes:
To matters nontrivial all the *nix variants use a different
more efficient replacement for poll.
Solaris has /dev/poll
*BSD (and OS X) has kqueue
Linux has epoll
Since this is 'cafe, here's a page has some performance testing of
epoll:
On 12/16/05, Einar Karttunen ekarttun@cs.helsinki.fi wrote:
To matters nontrivial all the *nix variants use a different
more efficient replacement for poll.
So we should find a library that offers a unified
interface for all of them, or implement one ourselves.
I am pretty sure such a library
On Fri, Dec 16, 2005 at 07:03:46AM +0100, Tomasz Zielonka wrote:
On 12/16/05, Einar Karttunen ekarttun@cs.helsinki.fi wrote:
To matters nontrivial all the *nix variants use a different
more efficient replacement for poll.
So we should find a library that offers a unified
interface for all
Hi,
Has anyone recently tried to install the graphics libraries
included on
http://haskell.org/soe/software.htm ?
I've tried to make the libraries, but I get these errors.
make: Entering directory
`/home/wchogg/coding/haskell/GraphicsLib/lib/x11'
ffihugs +G +LX_stub_ffi.c X.hs
Warning:
43 matches
Mail list logo
