- Haskell-Cafe - Haskell.org

Non-STM bounded queue
by Joel Reymont 16 Dec '05

16 Dec '05

Folks, I need to move away from STM (unfortunately) until I profile my program to my satisfaction. Profiling is somewhat crippled with STM in 6.4.1. I cannot do void and drag profiling, for examplel. I decided to abstract my mailboxes in a Queue module so that I could switch between STM and non-STM as needed. Please let me know what you think of this bounded queue implementation. --- module Queue where import Control.Monad import Control.Concurrent data Queue a = Queue !QSem !(Chan a) newQ :: Int -> IO (Queue a) newQ size = do sem <- newQSem size q <- newChan return $! Queue sem q writeQ :: Queue a -> a -> IO () writeQ (Queue sem q) x = do waitQSem sem writeChan q x readQ :: Queue a -> IO a readQ (Queue sem q) = do x <- readChan q signalQSem sem return x Thank, Joel -- http://wagerlabs.com/

1 0

+RTS -M800M
by Joel Reymont 16 Dec '05

16 Dec '05

Folks, I'm trying to restrict GHC to 800Mb of heap at runtime by passing in +RTS -M800M, the machine has 1Gb of memory and top shows free physical memory dropping below 175Mb. I suppose I'm missing something obvious or paying attention to the wrong statistics, Unix has a good VM manager after all. Are my runtime options correct, though? Thanks, Joel -- http://wagerlabs.com/

1 0

RE: Re[2]: [Haskell-cafe] Unbound threads and FFI
by Simon Peyton-Jones 16 Dec '05

16 Dec '05

I've added a FAQ. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Simon Marlow | Sent: 15 December 2005 09:26 | To: Bulat Ziganshin | Cc: Haskell-Cafe Cafe | Subject: RE: Re[2]: [Haskell-cafe] Unbound threads and FFI | | 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? | > | >> | safe unsafe | >> --------------+---------------- | >> -threaded | NO YES | >> no -threaded | YES YES | > | > there is also `threadsafe` specifier. i don't understand from the docs | > what it exactly means? | > | > ghc commentary says: | > | > To signal that you want an external call to be serviced by a separate | > OS thread, you have to add the attribute threadsafe to a foreign | > import declaration, i.e., | > | > foreign import "bigComp" threadsafe largeComputation :: Int -> IO () | > | > The distinction between 'safe' and thread-safe C calls is made so that | > we may call external functions that aren't re-entrant but may cause a | > GC to occur. | > | > The threadsafe attribute subsumes safe. | | threadsafe is deprecated; it is currently exactly the same as safe. We | thought at one time that it would be useful to have the distinction, but | it turned out to be impractical to implement safe that wasn't also | threadsafe. | | Cheers, | Simon | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: [Haskell-cafe] Unbound threads and FFI
by Simon Marlow 16 Dec '05

16 Dec '05

On 14 December 2005 15:34, Joel Reymont wrote: > On Dec 14, 2005, at 3:21 PM, Simon Marlow wrote: > >> this only happens in the -threaded RTS, in the non-threaded RTS a FFI >> call will block all the other Haskell threads. > > Just to be absolutely sure... Does the above apply to safe _and_ > unsafe FFI? > > I have been using the non-threaded runtime with unsafe FFI calls > (OpenSSL, Zlib) and I do not believe my runtime was being blocked. > Maybe I just didn't notice it, though. Maybe this little table will help: Do other Haskell threads get blocked during an FFI call? | safe unsafe --------------+---------------- -threaded | NO YES no -threaded | YES YES Cheers, Simon

3 2

QuickCheck arbitrary/co-arbitrary
by Joel Reymont 16 Dec '05

16 Dec '05

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/

2 1

RE: [Haskell-cafe] Unbound threads and FFI
by Simon Peyton-Jones 15 Dec '05

15 Dec '05

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: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Joel | Reymont | Sent: 14 December 2005 14:37 | To: Haskell-Cafe Cafe | Subject: [Haskell-cafe] Unbound threads and FFI | | How do unbound threads play with FFI? According to Simon PJ, each | foreign call will get its own OS thread if its blocked. | | How does GHC determine if the call is blocked? Does each call get its | own OS thread from the start? Sometime later? Does this depend on the | safe/unsafe specs of the foreign call? | | Does the above change if a threaded/non-threaded runtime is in use? | | Thanks, Joel | | -- | http://wagerlabs.com/ | | | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

official Cabal / Hackage wiki
by Isaac Jones 15 Dec '05

15 Dec '05

The new Cabal / Hackage wiki and bug tracking system is at: http://hackage.haskell.org/trac/hackage [1] Please report any Cabal (or HackageDB, cabal-get, etc) bugs there with "new ticket". Trac is pretty neat, you can inter-like wiki pages and tickets, as well as source code. Please feel free to start editing pages and adding information about Cabal. peace, isaac [1] Why the hackage...hackage redundancy? Well I'm basically hoping to roll out the "hackage" server as a community development site. As such, we have http://hackage.haskell.org/trac/ghc as well :)

1 0

RE: [Haskell-cafe] RE: [Haskell] TArray?
by Simon Marlow 15 Dec '05

15 Dec '05

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 the line). When/if a primitve > TArray is implemented, the Array-of-Tvars-approach could just be > replaced, and all programs which use the TArray would get an automatic > speed-boost. I like it when someone asks for something we've already done :-) http://www.haskell.org//pipermail/cvs-libraries/2005-December/004731.htm l Cheers, Simon

2 1

RE: [Haskell] TArray?
by Simon Marlow 15 Dec '05

15 Dec '05

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 to have a primitive STM array, the only >> problem with this is the extra complexity. One simplifying >> assumption is that it should consider changes at the level of the >> whole array, rather than per-element (otherwise you'd use an array >> of TVars). > > Actually, in that case it might be more useful to have a TMVar > containing an array. But I suspect the need for this use case is > small. I know a ton of uses for transactionally-updated arrays for > which the goal is to permit concurrent access to independent array > elements (concurrent hash tables come to mind as an obvious use case > where transactions make life vastly simpler). > > You might ask Tim Harris whether there's a reasonably simple, clever > way to do this > using arrays + CAS. I believe such a trick exists---you might end up > waking too many threads on a write, but you'd get read/write > concurrency at least. One simple plan is to log writes at the element level during a transaction (i.e. don't copy the whole array), but don't track *waiting* at the element level, so a thread waiting on a TArray will get woken up whenever the array is modified. You get read/write concurrency this way. Committing a transaction still has to lock the whole array during the update. Tim, do you know of any better schemes? Cheers, Simon

3 2

Re: Announcing Djinn, version 2004-12-11, a coding wizard
by oleg＠pobox.com 15 Dec '05

15 Dec '05

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 http://www.haskell.org/pipermail/haskell/2005-March/015423.html ``We ask the Haskell typechecker to derive us a function of the specified type. We get the real function, which we can then apply to various arguments. ... Informally, we converted from `undefined' to defined. It must be emphasized that no modifications to the Haskell compiler are needed, and no external programs are relied upon. In particular, however surprising it may seem, we get by without `eval' -- because Haskell has reflexive facilities already built-in.''

2 1

RE: Re[2]: [Haskell-cafe] Unbound threads and FFI
by Simon Marlow 15 Dec '05

15 Dec '05

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? > >> | safe unsafe >> --------------+---------------- >> -threaded | NO YES >> no -threaded | YES YES > > there is also `threadsafe` specifier. i don't understand from the docs > what it exactly means? > > ghc commentary says: > > To signal that you want an external call to be serviced by a separate > OS thread, you have to add the attribute threadsafe to a foreign > import declaration, i.e., > > foreign import "bigComp" threadsafe largeComputation :: Int -> IO () > > The distinction between 'safe' and thread-safe C calls is made so that > we may call external functions that aren't re-entrant but may cause a > GC to occur. > > The threadsafe attribute subsumes safe. threadsafe is deprecated; it is currently exactly the same as safe. We thought at one time that it would be useful to have the distinction, but it turned out to be impractical to implement safe that wasn't also threadsafe. Cheers, Simon

1 0

RE: [Haskell-cafe] Top-level TVars
by Simon Marlow 15 Dec '05

15 Dec '05

On 14 December 2005 20:39, Joel Reymont wrote: >> On Wed, Dec 14, 2005 at 02:17:17PM -0000, 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 common these up - after all, it's the >>> same expression, so it must yield the same result, right? > > Do these have to be within the same module for the CSE optimization > to kick in? Right now, yes. But there's no guarantee that GHC might not get cleverer in the future. We're skating on really thin ice here. I'm not particularly keen on re-opening the discussion about top-level IO, but we do need *something* better. Cheers, Simon

1 0

RE: [Haskell-cafe] Top-level TVars
by Simon Peyton-Jones 15 Dec '05

15 Dec '05

Yes, they do | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] 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 02:17:17PM -0000, 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 common these up - after all, it's the | >> same | >> expression, so it must yield the same result, right? | | Do these have to be within the same module for the CSE optimization | to kick in? | | -- | http://wagerlabs.com/ | | | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

[Haskell-cafe] Announcing Djinn, version 2004-12-11, a coding wizard
by Lennart Augustsson 15 Dec '05

15 Dec '05

Howdy, y'all! I've written a small program that takes a (Haskell) type and gives you back a function of that type if one exists. It's kind of fun, so I thought I'd share it. It's probably best explained with a sample session. calvin% djinn Welcome to Djinn version 2005-12-11. Type :h to get help. # Djinn is interactive if not given any arguments. # Let's see if it can find the identity function. Djinn> f ? a->a f :: a -> a f x1 = x1 # Yes, that was easy. Let's try some tuple munging. Djinn> sel ? ((a,b),(c,d)) -> (b,c) sel :: ((a, b), (c, d)) -> (b, c) sel ((_, v5), (v6, _)) = (v5, v6) # We can ask for the impossible, but then we get what we # deserve. Djinn> cast ? a->b -- cast cannot be realized. # OK, let's be bold and try some functions that are tricky to write: # return, bind, and callCC in the continuation monad Djinn> type C a = (a -> r) -> r Djinn> returnC ? a -> C a returnC :: a -> C a returnC x1 x2 = x2 x1 Djinn> bindC ? C a -> (a -> C b) -> C b bindC :: C a -> (a -> C b) -> C b bindC x1 x2 x3 = x1 (\ c15 -> x2 c15 (\ c17 -> x3 c17)) Djinn> callCC ? ((a -> C b) -> C a) -> C a callCC :: ((a -> C b) -> C a) -> C a callCC x1 x2 = x1 (\ c15 _ -> x2 c15) (\ c11 -> x2 c11) # Well, poor Djinn has a sweaty brow after deducing the code # for callCC so we had better quit. Djinn> :q Bye. To play with Djinn do a darcs get http://darcs.augustsson.net/Darcs/Djinn or get http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz Then just type make. (You need a Haskell 98 implementation and some libraries.) And then start djinn. For the curious, Djinn uses a decision procedure for intuitionistic propositional calculus due to Roy Dyckhoff. It's a variation of Gentzen's LJ system. This means that (in theory) Djinn will always find a function if one exists, and if one doesn't exist Djinn will terminate telling you so. This is the very first version, so expect bugs. :) Share and enjoy. -- Lennart

4 4

RE: [Haskell-cafe] Top-level TVars
by Simon Marlow 14 Dec '05

14 Dec '05

On 14 December 2005 10:11, Joel Reymont wrote: > I'm a bit lost in the discussion. Why do I need -fno-cse and how do I > seq at the top-level? > > On Dec 14, 2005, at 10:05 AM, Tomasz Zielonka wrote: > >> On Wed, Dec 14, 2005 at 10:03:42AM -0000, Simon Marlow wrote: >>> Well sure, but it's only a temporary problem. And you also have to >>> tell them to use {-# NOINLINE #-} and -fno-cse :-) >> >> -fno-cse is also neccesary? Oops, I didn't know that. Can I simply >> place it in {-# OPTIONS -fno-cse #-} ? 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 common these up - after all, it's the same expression, so it must yield the same result, right? To turn this off, we use -fno-cse. It's good practice to use -fno-cse whenever you use top-level mutable objects of any kind. You can put it in the source file: {-# OPTIONS_GHC -fno-cse #-} at the top of your file. Cheers, Simon

3 2

RE: [Haskell-cafe] killThread and FFI calls
by Simon Marlow 14 Dec '05

14 Dec '05

On 14 December 2005 15:35, Joel Reymont wrote: > On Dec 14, 2005, at 3:22 PM, Simon Marlow wrote: > >> On 14 December 2005 14:26, Joel Reymont wrote: >> >>> How does killThread work with FFI calls? What happens at the low >>> level when a thread is blocked on an FFI call and received a >>> KillThread exception? Does it exit immediately via some GHC magic or >>> is the exception caught when the FFI call returns? >> >> The latter. > > Does this change if I kill a thread that's blocked on I/O in a > threaded runtime? > > Does it get cleaned up immediately? A thread blocked on ordinary Handle-based I/O can be killed, because blocked Handle I/O is implemented using communication with the I/O manager thread, so it isn't an FFI call under the hood. Cheers, Simon

1 0

RE: [Haskell-cafe] killThread and FFI calls
by Simon Marlow 14 Dec '05

14 Dec '05

On 14 December 2005 14:26, Joel Reymont wrote: > How does killThread work with FFI calls? What happens at the low > level when a thread is blocked on an FFI call and received a > KillThread exception? Does it exit immediately via some GHC magic or > is the exception caught when the FFI call returns? The latter. Cheers, Simon

2 1

RE: [Haskell-cafe] Unbound threads and FFI
by Simon Marlow 14 Dec '05

14 Dec '05

On 14 December 2005 14:37, Joel Reymont wrote: > How do unbound threads play with FFI? According to Simon PJ, each > foreign call will get its own OS thread if its blocked. > > How does GHC determine if the call is blocked? Does each call get its > own OS thread from the start? Sometime later? When a thread exits Haskell to make an FFI call, another OS thread takes over running the other Haskell threads. If we don't have another OS thread available, we start one. > Does this depend on the safe/unsafe specs of the foreign call? this only happens for safe calls, not unsafe. > Does the above change if a threaded/non-threaded runtime is in use? this only happens in the -threaded RTS, in the non-threaded RTS a FFI call will block all the other Haskell threads. Cheers, Simon

2 1

GHC internal error: traverse_weak_ptr_list: not WEAK
by Joel Reymont 14 Dec '05

14 Dec '05

loadtest: internal error: traverse_weak_ptr_list: not WEAK Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ Has anyone seen this before? I got this after running a 1,300 socket connections for a while (probably x3 threads overall). Any workarounds? Thanks, Joel -- http://wagerlabs.com/

1 1

Unbound threads and FFI
by Joel Reymont 14 Dec '05

14 Dec '05

How do unbound threads play with FFI? According to Simon PJ, each foreign call will get its own OS thread if its blocked. How does GHC determine if the call is blocked? Does each call get its own OS thread from the start? Sometime later? Does this depend on the safe/unsafe specs of the foreign call? Does the above change if a threaded/non-threaded runtime is in use? Thanks, Joel -- http://wagerlabs.com/

1 0

killThread and FFI calls
by Joel Reymont 14 Dec '05

14 Dec '05

Folks, How does killThread work with FFI calls? What happens at the low level when a thread is blocked on an FFI call and received a KillThread exception? Does it exit immediately via some GHC magic or is the exception caught when the FFI call returns? Thanks, Joel -- http://wagerlabs.com/

1 0

Announcing Djinn, new version 2004-12-13
by Lennart Augustsson 14 Dec '05

14 Dec '05

There is a new version of Djinn available, with two notable new features: Haskell data types can be defined and the found functions are sorted (heuristically) to present the best one first. To play with Djinn do a darcs get http://darcs.augustsson.net/Darcs/Djinn or get http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz Then just type make. (You need a Haskell 98 implementation and some libraries.) And then start djinn. `-- Lennart

2 2

RE: [Haskell-cafe] Re: Bringing Erlang to Haskell
by Simon Peyton-Jones 14 Dec '05

14 Dec '05

There's a (GHC-specific) Wiki page on concurrent programming in GHC, in the new GHC Wiki. http://hackage.haskell.org/trac/ghc/wiki/GhcConcurrency Feel free to add more info to it. I've dropped in the links below. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Robert Dockins | Sent: 13 December 2005 15:18 | To: Joel Reymont | Cc: Haskell-Cafe Cafe | Subject: Re: [Haskell-cafe] Re: Bringing Erlang to Haskell | | BTW, there has already been some work in this area. | | http://www-i2.informatik.rwth-aachen.de/~stolz/dhs/ | http://www.informatik.uni-kiel.de/~fhu/PUBLICATIONS/1999/ifl.html | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: [Haskell-cafe] Top-level TVars
by Simon Marlow 14 Dec '05

14 Dec '05

On 14 December 2005 09:57, Tomasz Zielonka wrote: > On Wed, Dec 14, 2005 at 09:51:16AM -0000, Simon Marlow wrote: >>> Here is an example how you can initialize a top-level STM variable. >>> http://www.uncurry.com/repos/TimeVar/TimeVar.hs >>> It just forks a new thread inside unsafePerformIO, it runs >>> "atomically" in it and passes the result through ordinary MVar. >> >> A cheaper way is just to seq the top-level TVar at the beginning of >> Main.main. > > Yes, I tried that approach. However, imagine telling users of > your library to do that in every program (withSocketsDo comes > to mind). Well sure, but it's only a temporary problem. And you also have to tell them to use {-# NOINLINE #-} and -fno-cse :-) Cheers, Simon

3 2

RE: [Haskell-cafe] Top-level TVars
by Simon Marlow 14 Dec '05

14 Dec '05

On 13 December 2005 18:34, Tomasz Zielonka wrote: > On Tue, Dec 13, 2005 at 06:08:23PM +0000, Joel Reymont wrote: >> Can this be done now or is this a GHC 6.5 feature? >> >> My combination of unsafePerformIO with atomically $ newTVar does not >> seem to be working. > > Here is an example how you can initialize a top-level STM variable. > http://www.uncurry.com/repos/TimeVar/TimeVar.hs > It just forks a new thread inside unsafePerformIO, it runs > "atomically" in it and passes the result through ordinary MVar. A cheaper way is just to seq the top-level TVar at the beginning of Main.main. Cheers, Simon

2 1

RE: [Haskell-cafe] Top-level TVars
by Simon Peyton-Jones 14 Dec '05

14 Dec '05

newTVarIO in the HEAD, and therefore it's in any nightly-build snapshot, which you can freely download. The next major release will be 6.6, but it's a few months off. Meanwhile I hope you can use the workaround that Tomasz posted. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Joel | Reymont | Sent: 13 December 2005 18:08 | To: Haskell-Cafe Cafe | Subject: [Haskell-cafe] Top-level TVars | | Can this be done now or is this a GHC 6.5 feature? | | My combination of unsafePerformIO with atomically $ newTVar does not | seem to be working. | | Thanks, Joel | | P.S. What is the ETA for 6.5? | | On Mon, Dec 05, 2005 at 10:50:13AM -0000, Simon Peyton-Jones wrote: | > | > It turns out to be easy to provide | > | > newTVarIO :: a -> IO (TVar a) | > | > which you can call from inside 'unsafePerformIO'. That means you can | > allocate top-level TVars without fuss. | > | | -- | http://wagerlabs.com/ | | | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Top-level TVars
by Joel Reymont 13 Dec '05

13 Dec '05

Can this be done now or is this a GHC 6.5 feature? My combination of unsafePerformIO with atomically $ newTVar does not seem to be working. Thanks, Joel P.S. What is the ETA for 6.5? On Mon, Dec 05, 2005 at 10:50:13AM -0000, Simon Peyton-Jones wrote: > > It turns out to be easy to provide > > newTVarIO :: a -> IO (TVar a) > > which you can call from inside 'unsafePerformIO'. That means you can > allocate top-level TVars without fuss. > -- http://wagerlabs.com/

2 1

FreeBSD: Max # of sockets opened
by Joel Reymont 13 Dec '05

13 Dec '05

Folks, I need some help from those of you with a FreeBSD box. It looks like 'ulimit -n' on FreeBSD lets you have 10k+ file descriptors open per process. FD_SETSIZE is 1024 in the system headers, though. GHC relies on this value (see ghc/rts/Select.c). Normally, you will get the EMFILE error if you try to open more sockets than what is allowed with 'ulimit -n'. If you allow yourself more than 1024 descriptors per process then you do not get this error but... This seems to lead to a situation where you open more than 1024 sockets and shortly afterwards get 'connection resets' for some or all of your sockets. Maybe just those above 1024, I have not determined this precisely. My question is this: is it possible to get a higher number of open sockets by editing the system header files on FreeBSD and recompiling GHC? Has anyone tried this before? How high can you go? Thanks, Joel -- http://wagerlabs.com/

2 3

Fwd: [Haskell] ANNOUNCE: Process library (for dataflow-oriented programming?)
by Bulat Ziganshin 13 Dec '05

13 Dec '05

This is a forwarded message From: Bulat Ziganshin <bulatz(a)HotPOP.com> To: haskell(a)haskell.org Date: Thursday, December 08, 2005, 1:36:05 AM Subject: [Haskell] ANNOUNCE: Process library (for dataflow-oriented programming?) ===8<==============Original message text=============== Hello haskell, Joel's program (discussed in cafe), which now uses MVars instead of Channels to send data between threads, may be a good example of dataflow-driven program: it consists of many hundreds of threads and when one thread sends data to another through MVar, this thread in most cases goes to sleep until receiving thread will process previous value of this MVar. so, threads are waked up and asleep according to passing values between them, and the whole program executes in order defined by these data dependencies, as opposite to the order of program statements one year ago i developed small library, which can be helpful if you want to use such style of programming. its ideas are modelled after Unix pipes, which are widely used to assemble complex data processing "engines" from simple "details". really this library is very thin layer over direct using of forkOS, channels and MVars; nevertheless, is is very convenient and beatiful you can download library as http://freearc.narod.ru/Process.tar.gz this page also contains sources of my program where you can find examples of using library in real toy :) below is a guide to library usage to create pipe, which contains 3 processes - "producer", "transformer" and "consumer": runP ( producer |> transformer |> consumer ) each process in pipe runned in separate Haskell thread. process is represented by ordinary Haskell function which gets an additional parameter - handle, which can be used to receive data from previous process in pipe (using receiveP) and send data to the next process (using sendP). for example, abovementioned processes can be implemented as: producer handle = mapM_ (sendP handle) [1..10] transformer handle = replicateM_ 10 $ do x <- receiveP handle sendP handle (x*2) consumer handle = replicateM_ 10 $ do x <- receiveP handle print x if first process in pipe tries to use receiveP or last process in pipe tries to use sendP, then run-time exception is generated. number of processes in pipe can be arbitrary. because each process is just ordinary Haskell function, you can add additional parameters to processes when constructing pipes: runP ( producer |> multiple 2 |> multiple 3 |> consumer ) multiple n handle = replicateM_ 10 $ do x <- receiveP handle sendP handle (x*n) moreover, you can construct pipe or part of it as ordinary data value, which then can be runned by runP: let pipe = case multipliers of [x] -> multiple x [x,y] -> multiple x |> multiple y [x,y,z] -> multiple x |> multiple y |> multiple z _ -> \handle -> fail "Zero or too much multipliers" runP ( producer |> pipe |> consumer ) there is also "back channel", which can be used to "return" data to previous process in the pipe, its operations is send_backP and receive_backP. it can be used to return acknowledgments, synchronize processes or to return resources back. brief example of its usage: producer: sendP pipe (buf,len) consumer: ; ; (buf,len) <- receiveP pipe ; hPutBuf file buf len ; send_backP pipe () receive_backP pipe ; --now we know that buf is free ; (i organized lines to show execution order) if processes joined in pipe with "|>" then channel between them uses MVar, so at any moment it may contain no more than 1 element. if channel between two processes is created with "|>>>" then Chan is used, which can contain arbitrary number of data items. be careful with such channels, because they can grow to unlimited size. "|>" and "|>>>" can be arbitrarily combined in one pipe: runP ( producer |>>> multiple 2 |> multiple 3 |>>> consumer ) back channel (used by send_backP and receive_backP) are always multi-element (uses Chan) runP returns when all processes in pipe are finished. if any process in pipe generates uncaught exception, then all processes in pipe are killed and this exception is re-raised in thread called runP pipe or single process can also be runned in background using runAsyncP: handle <- runAsyncP (multiple 2) handle returned here can be used to interact with first and last processes in pipe, in contrast to runP: handle <- runAsyncP (multiple 2) sendP handle 1 res <- receiveP handle of course, pipe runned asynchronously is not required to perform input, output, or both: handle <- runAsyncP ( producer |> transformer ) handle <- runAsyncP ( transformer |> consumer ) handle <- runAsyncP ( producer |> transformer |> consumer ) currently channels to "open ends" of background pipe are always one-element (uses MVars). types of channels inside pipe are determined, as usual, by using the "|>" or "|>>>" operator you can wait for finishing of asynchronous pipe with "joinP handle" you can "replace" process, which is runned in pipe, with another process or pipe by using runFuncP: transformer handle = runFuncP ( multiple 2 |> multiple 3 ) (receiveP handle) (send_backP handle) (sendP handle) (receive_backP handle) actually, runFuncP just executes its pipe using 4 supported functions for interaction with first and last pipe processes. to make this obvious i will say how runP can be implemented in terms of runFuncP: runP p = runFuncP p (error "First process in runP tried to receive") (error "First process in runP tried to send_back") (error "Last process in runP tried to send") (error "Last process in runP tried to receive_back") runFuncP returns when all processes in its pipe are finished. using it, you can create unlimited number of scenarios: running several runFuncP sequentially to deal with different parts of your data, process part of data itself and part with runFuncP, "redirect" your input to process runned by runFuncP but consume output from runFuncP in other way: consumer handle = runFuncP ( multiple 4 ) (receiveP handle) undefined print -- output action undefined runFuncP can also be used in other cases when we need to run single process or whole pipe "imitating" its interaction with "external world" by some functions: runFuncP transformer readLn -- input action undefined print -- output action undefined it will also be interesting to have some functions which can just insert "filtering" process or pipe on input or output side of current process: transformer channel = do channel <- insertInputFilterP (multiple 2) channel channel <- insertOutputFilterP (multiple 4) channel x <- receiveP channel sendP channel (x+1) ... but i don't need it and therefore this currently is not implemented the library also don't contains routines to check that input is ready or output can be done (because i don't need it and it is a bad programming style), nor routines to check for EOF (i prefer to encode this explicitly in structure of data sent across channels; you also can wrap your data in Maybe type and use Nothing to encode EOF) -- Best regards, Bulat mailto:bulatz@HotPOP.com _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell ===8<===========End of original message text=========== -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 2

Bringing Erlang to Haskell
by Joel Reymont 13 Dec '05

13 Dec '05

Folks, I love the Erlang multi-processing experience and think that a lot of the mistakes that I made could be avoided. What I want to have is 1) Processes, aka threads with single-slot in/out mailboxes 2) A facility to keep a list of such processes and send events to them using their process id 3) A socket reader/writer abstraction that communicates with the outside world using using its mailboxes Probably some other things but I would start with the above. I also want to use STM for this. One particular thing that bugs me is that I cannot really use TChan for thread mailboxes. I don't think I experienced this problem with Erlang but using a TChan with a logger thread quickly overwhelms the logger and fills the TChan and a lot (hundreds? thousands) of other threads are logging to it. Someone said it's because the scheduler would give ther other threads proportionally more attention. I found single-slot mailboxes (TMVar) to work much better as they pace the overall message flow. Using them means that asynchronous messages cannot be implemented, though. Please correct me if I'm wrong. I'll update my blog as I move forward. Thanks, Joel -- http://wagerlabs.com/

5 10

trick to easily generate Eq/Ord instances
by Bulat Ziganshin 13 Dec '05

13 Dec '05

Hello sometimes, Eq/Ord classes can't be derived automatically because we need to comare only part of fields. in such situations i use the following trick to easify generation of class instances: data ArchiveBlock = ArchiveBlock { blArchive :: Archive , blType :: BlockType , blCompressor :: Compressor , blPos :: Integer , blOrigSize :: Integer , blCompSize :: Integer , blCRC :: CRC , blFiles :: Int } instance Eq ArchiveBlock where (==) = map2eq $ map3 (blArchive,blPos,blCRC) instance Ord ArchiveBlock where compare = map2cmp $ map2 (blArchive,blPos) {- instance Ord ArchiveBlock where compare = map2cmp blPos -- for comparision on just one field -} -- Utility functions map2 (f,g) a = (f a, g a) map3 (f,g,h) a = (f a, g a, h a) keyval f x = (f x, x) -- |Return pair containing computed key and original value map2cmp f x y = (f x) `compare` (f y) -- |Converts "key_func" to "compare_func" map2eq f x y = (f x) == (f y) -- |Converts "key_func" to "eq_func" -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 1

The Price of Performance
by Joel Reymont 13 Dec '05

13 Dec '05

I thought this would be of interest to the Haskell community: http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=330 "The ever-growing popularity of small multiprocessors is exposing more programmers to parallel hardware. More tools to spot correctness and performance problems are becoming available (e.g., thread checkers8 and performance debuggers9). Also, a few expert programmers can write efficient threaded code that is in turn leveraged by many others. Fast-locking and thread-efficient memory allocation libraries are good examples of programming work that is highly leveraged." Viva le STM! -- http://wagerlabs.com/

1 0

Tricky exception handling
by Joel Reymont 13 Dec '05

13 Dec '05

Folks, I have a thread that launches socket reader and writer threads. My intent is to notify the main thread when an exception is caught by the reader/writer. Is this code proper? --- withException :: (Event a -> IO ()) -> IO () -> IO Bool withException post action = handle (\e -> do case e of AsyncException ThreadKilled -> return () _ -> post $ NetworkError e return False ) $ do { action; return True } writeLoop :: (Event a -> IO ()) -> Handle -> (SSL, BIO, BIO) -> IO () writeLoop post h ssl = do go <- withException post $ do cmd <- read h ssl post $! Cmd $! cmd when go $ writeLoop post h ssl --- Thanks, Joel -- http://wagerlabs.com/

2 4

Opening the same file multiple times
by Einar Karttunen 13 Dec '05

13 Dec '05

Hello It seems that opening the same file multiple times (one writer and multiple readers) is not supported at least on *nix with GHC. I want to use one Handle to use append data till the end of the file while other Handles perform random access IO with seeks on the file. Sharing the same Handle for all the threads is not possible since they perform seeks and may thus mess each other up. Hiding the Handle behind a mutex would limit concurrency more than I like. Thus I wanted to open multiple Handles to the file, but this seems quite hard. My best guess is to create a function like: #ifdef mingw32_HOST_OS openUnlocked fn mode = openBinaryFile fn mode #else openUnlocked fn mode = withMVar mutex $ do h <- openBinaryFile fn mode fd <- handleToFd h unlockFile $ fromIntegral fd return h {-# NOINLINE mutes #-} mutex = unsafePerformIO $ newMVar () #endif Is there really no simpler solution? - Einar Karttunen

3 4

[Newbie] Why or why not haskell ?
by Christophe Plasschaert 12 Dec '05

12 Dec '05

First, i'd like to say good day to everybody. I didn't find enough information to anwser this question: Being interesting in learning another way of programming besides C and perl i started watching other languages. These are my candidates: - ada; - erlang; - clisp or scheme; and of course - haskell. Haskell seems very interesting indeed (monadic, STM, a good library). Maybe some of you know some or all of these languages and can explain me some pros/cons about them especially for network programming. Thanks for your attention. Have a nice day. C. Plasschaert

10 16

Re: [Haskell-cafe] Opening the same file multiple times
by Donn Cave 12 Dec '05

12 Dec '05

Quoth Einar Karttunen <ekarttun(a)cs.helsinki.fi>: | On 11.12 22:26, Donn Cave wrote: | > Quoth Einar Karttunen <ekarttun(a)cs.helsinki.fi>: | > | It seems that opening the same file multiple times (one writer | > | and multiple readers) is not supported at least on *nix with | > | GHC. I want to use one Handle to use append data till the | > | end of the file while other Handles perform random access | > | IO with seeks on the file. | > | > How is it not supported? What happens with something like this ... | *** Exception: z: openFile: resource busy (file is locked) Oh. Well, that's unfortunate, but at least I see it is documented. I guess that explains why your solution uses unlockFile. I suppose you might be able to use Posix.IO functions instead, but that would probably be even more trouble than your work-around. Donn Cave, donn(a)drizzle.com

2 3

RE: [Haskell-cafe] Opening the same file multiple times
by Simon Marlow 12 Dec '05

12 Dec '05

On 12 December 2005 17:53, Donn Cave wrote: > Quoth Einar Karttunen <ekarttun(a)cs.helsinki.fi>: > ... >> *** Exception: z: openFile: resource busy (file is locked) > > Now that I have access to a platform where ghc builds, I can > duplicate your results - and in case it helps, here's another > work-around. Apparently this "feature" uses POSIX filesystem > locks, because it appears that we can exploit the brain-damaged > semantics of that system: when a process closes a file, all > its locks are cleared - whether they were acquired through that > file descriptor or another unrelated open. It may be the first > time anyone has ever benefited from this! > > import IO > > main = do > fc <- openFile "z" ReadMode -- sacrificial handle > fr <- openFile "z" ReadMode > hClose fc > fa <- openFile "z" AppendMode > hPutStr fa "append this line\n" > hGetLine fr >>= print > > If you may need to open more read handles later, you can add > another extra close after the append handle. Thank you (I suppose :-) for exposing a bug in GHC's file locking. It doesn't have anything to do with POSIX filesystem locks, FWIW, it's just a bug, in some very old code. Cheers, Simon

1 0

syscall, sigpause and EINTR on Mac OSX
by Joel Reymont 12 Dec '05

12 Dec '05

Folks, I'm kind of stuck on this and can't figure it out... Take a look at the trace below, this is Mac OSX Tiger. (gdb) where #0 0x90006068 in syscall () #1 0x9004420c in sigpause () #2 0x001791b8 in awaitUserSignals () at Signals.c:256 #3 0x0012e1a8 in schedule (mainThread=0x1300360, initialCapability=0x0) at Schedule.c:518 #4 0x0012f340 in waitThread_ (m=0x1300360, initialCapability=0x0) at Schedule.c:2156 #5 0x0012f224 in scheduleWaitThread (tso=0x15c0000, ret=0x0, initialCapability=0x0) at Schedule.c:2050 #6 0x0012ba18 in rts_evalLazyIO (p=0x215254, ret=0x0) at RtsAPI.c:459 #7 0x0001ea7c in main (argc=4, argv=0x0) at Main.c:104 (gdb) p16 $r22 0x40: Cannot access memory at address 0x40 My program is currently stuck here. The man pages say that sigpause will only terminate by being interrupted and EINTR will be the errno. EINTR is signal 2, the same one that I'm trapping and the one sent when ^C is pressed. This probably explains why my signal handler is getting hit from time to time without any input from me. My program then exits and leaves me very puzzled as the whole thing looks like someone sneaked up to my keyboard and hit ^C to interrupt the program. I'm not making any sense of this. Why would someone be calling sigpause and making it interrupt my program? How can I work around this? I guess I'll poke around the ghc internals a bit and see what's cooking. Thanks, Joel -- http://wagerlabs.com/

6 37

Differences in optimisiation with interactive and compiled mode
by Branimir Maksimovic 12 Dec '05

12 Dec '05

It seems that compiled programs run better then interactive ones. Following program with GHC works with pretty good performance in comparison to C++ one with similar but non recursive algorithm and beats it in memory consumtion. It only takes about 2mb of ram somehow when running compiled. I'm really amased. But in interactive mode both GHC and Hugs fail due heap exhaustion and running takes ages.Please can someone explain why? I intent to use only compiled Haskell anyway so GHC satisfies. Greetings, Bane. program performs search replace on a String module Main where import IO main = do hSetBuffering stdout LineBuffering let sr = "search" rp = "replace" str= " able search sea baker search charlie \"" out = searchr sr rp (take (1000000*(length str)) $ infinite str) out1 = searchr sr rp (take (1000001*(length str)) $ infinite str) putStrLn $ "Working:" ++ sr ++ " " ++ rp ++ " " ++ str putStrLn $ (show (out == out1)) ++ "\n" ++ "\nDone\n" {- search replace " able search baker search charlie " -} ------------------------------------------------------------------------------- infinite xs = xs ++ infinite xs searchr :: String->String->String -> String searchr [] _ xs = xs searchr _ [] xs = xs searchr _ _ [] = [] searchr sr rp xs | fst fnd = rp ++ searchr sr rp (snd $ snd fnd) | otherwise = (reverse $ fst $ snd fnd) ++ searchr sr rp (snd $ snd fnd) where fnd = searchr' sr xs "" searchr' :: String->String->String -> (Bool,(String,String)) searchr' (sr:srs) xs fndSoFar = searchr'' (sr:srs) xs fndSoFar sr searchr'' :: String->String->String->Char -> (Bool,(String,String)) searchr'' [] xs fnd _ = (True,(fnd,xs)) searchr'' _ [] fnd _ = (False,(fnd,[])) searchr'' (sr:srs) (x:xs) fndSoFar s | sr == x = searchr'' srs xs xxs s | otherwise = (False,searchr''' s xs xxs) -- (False,(xxs,xs)) where xxs = x:fndSoFar searchr''' :: Char->String->String -> (String,String) searchr''' sr [] fndSoFar = (fndSoFar,[]) searchr''' sr (x:xs) fndSoFar | sr /= x = searchr''' sr xs (x:fndSoFar) | otherwise = (fndSoFar,x:xs) ------------------------------------------------------------------------------- _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

8 41

RE: [Haskell-cafe] STM, orElse and timed read from a channel
by Simon Marlow 12 Dec '05

12 Dec '05

On 12 December 2005 10:09, Joel Reymont wrote: > While we are waiting for ghc 6.6, could the same effect be achieved > by launching the computation that writes to t with forkIO? Certainly. registerTimeout is just an optimisation that avoids creating a new thread each time. Cheers, Simon > On Nov 29, 2005, at 12:00 PM, Simon Marlow wrote: > >> threadDelay is IO-only; there's no way to use threadDelay in an STM >> transaction. For example, if you want to wait for a TVar to go from >> Nothing to Just x with a timeout, you could do this: >> >> readOrTimeout :: TVar (Maybe a) -> Int -> STM (Maybe a) >> readOrTimeout t secs = do timeout <- registerTimeout secs >> let check_timeout = do >> b <- readTVar timeout >> if b then return Nothing else retry >> check_t = do >> m <- readTVar t >> case m of >> Nothing -> retry >> Just x -> return x >> atomically $ check_timeout `orElse` check_t

1 0

RE: [Haskell-cafe] Opening the same file multiple times
by Simon Marlow 12 Dec '05

12 Dec '05

On 12 December 2005 14:01, Einar Karttunen wrote: > On 12.12 12:06, Duncan Coutts wrote: >> It states in the Haskell Report 21.2.3: >> >> http://haskell.org/onlinereport/io.html > > Thanks, for the pointer, but am looking for an extension > in the non-haskell98 API to do it. > > It seems that things are quite problematic: > > 1) Use openFile or GHC.Handle.openFd > > Works in Hugs, fails as the standard mandates in GHC > due to locking. This is fine. You can trick openFd into not locking the file by passing (Just RawDevice) as the file type. Ugly, but should work. Cheers, Simon

1 0

RE: [Haskell-cafe] Re: syscall, sigpause and EINTR on Mac OSX
by Simon Marlow 12 Dec '05

12 Dec '05

On 11 December 2005 17:19, Joel Reymont wrote: > Nothing like answering your own questions... > > There's no deadlock information for the threaded version of the > runtime so I would not have deadlock information if I were to compile > with -threaded. This doesn't really help you right now, but -threaded has better deadlock detection in GHC 6.6. Cheers, Simon

1 0

RE: [Haskell] fptools mirror in darcs ready for testing
by Simon Marlow 12 Dec '05

12 Dec '05

On 08 December 2005 18:21, Malcolm Wallace wrote: >> http://cvs.haskell.org/darcs/ghc >> http://cvs.haskell.org/darcs/libraries > > It suddenly occurs to me that there are other projects in CVS > that have not yet been converted to darcs, e.g. Hugs98 and nhc98. > Are there plans to do so? If not, then since both of these depend > on the libraries tree, there will need to be some other plan to cope > with the eventual dropping of the libraries CVS archive. > > There are also a bunch of other smaller, more stand-alone projects > like cpphs, hat, ohugs, programmatica, timber. The long-term plan > for Hat is to depend on the libraries tree, although it does not do > so currently. Hugs98 and nhc98 both currently depend on cpphs. It might be worthwhile someone setting up a mirror from darcs->CVS to keep the libraries CVS tree up to date, to help support these other projects that aren't moving to darcs yet (or at all?). John Goerzen has told me that setting up a reverse mirror should be possible, but not at all trivial - and I think he's already done his fair share for the community by setting up the darcs mirror for fptools :-) So we're looking for a volunteer... Cheers, Simon

2 1

RE: [Haskell-cafe] GHCi and threads, was Connecting to a running process (REPL)
by Simon Marlow 12 Dec '05

12 Dec '05

On 10 December 2005 23:45, Rohan Drape wrote: > On Tue Dec 6 15:01:45 EST 2005 Tomasz Zielonka wrote: > >> Unfortunately it seems that forkIO'ed threads are freezed when GHCi >> is waiting for command-line input. I bet it would be possible to let >> the threads work in the background. I think the current behaviour is >> caused by using readline, which is a foreign library. Or it is by >> design? > > I also think this is unfortunate, and would like to know if this can > be worked around (ie. I could happily live without readline if that is > the issue and it can be switched off). The fix is trivial: we have to add -threaded when we link GHCi. The only reason I haven't done this yet is because I'm being cautious; the threaded RTS is a fair bit more complex that the non-threaded RTS. I think we'll schedule this for 6.6 though. Cheers, Simon

1 0

RE: [Haskell-cafe] STM commit hooks
by Simon Marlow 12 Dec '05

12 Dec '05

On 29 November 2005 12:40, Einar Karttunen wrote: > Hello > > I have been playing with STM and want to log transactions to disk. > Defining a logging function like: > > log h act = unsafeIOToSTM $ hPrint h act > > works most the time. Aborts can be handled with: > > abort h = log h Abort >> retry > atomic' h act = atomically (act `orElse` abort h) > > But is it possible to handle a commit? > > commit h = unsafeIOToSTM (hPrint h Commit >> hSync h) > atomically2 h act = atomically ((act >> commit h) `orElse` abort h) > > This won't work because the transaction is validated and > maybe aborted after the commit is logged to disk. > > Another alternative would be: > > atomically3 h act = atomically (act `orElse` abort h) >> atomically > (commit h) If I'm understanding you correctly, what you need is to log the commit operation before another thread commits and logs a transaction. So you just need to close this race hole at the '>>' in the above definition. How about this: log_lock <- newTMVar () atomically3 h act = do atomically (do act; takeTMVar log_lock `orElse` abort h) hPrint h Commit atomically (putTMVar log_lock ()) does that work? Cheers, Simon

2 1

STM commit hooks
by Einar Karttunen 12 Dec '05

12 Dec '05

Hello I have been playing with STM and want to log transactions to disk. Defining a logging function like: log h act = unsafeIOToSTM $ hPrint h act works most the time. Aborts can be handled with: abort h = log h Abort >> retry atomic' h act = atomically (act `orElse` abort h) But is it possible to handle a commit? commit h = unsafeIOToSTM (hPrint h Commit >> hSync h) atomically2 h act = atomically ((act >> commit h) `orElse` abort h) This won't work because the transaction is validated and maybe aborted after the commit is logged to disk. Another alternative would be: atomically3 h act = atomically (act `orElse` abort h) >> atomically (commit h) But this does not work either. Given Trx1 and Trx2, the following may occur: 1) Trx1 commits <thread switch> 2) Trx2 commits (and depends on Trx1) 3) Trx2 commit is logged to disk <system crash> This means that the log would be inconsistent. Is there a way to implement the commit that works? - Einar Karttunen

2 1

RE: [Haskell-cafe] STM, orElse and timed read from a channel
by Simon Marlow 12 Dec '05

12 Dec '05

threadDelay is IO-only; there's no way to use threadDelay in an STM transaction. For example, if you want to wait for a TVar to go from Nothing to Just x with a timeout, you could do this: readOrTimeout :: TVar (Maybe a) -> Int -> STM (Maybe a) readOrTimeout t secs = do timeout <- registerTimeout secs let check_timeout = do b <- readTVar timeout if b then return Nothing else retry check_t = do m <- readTVar t case m of Nothing -> retry Just x -> return x atomically $ check_timeout `orElse` check_t Cheers, Simon On 29 November 2005 10:11, Joel Reymont wrote: > Simon, > > How is this easier than just calling threadDelay? > > Ideally, I would be looking for something like reading from a TVar > with a timeout. So that you either get a Nothing (timeout) or the > value from the TVar. Can I implement it using the GHC timeout thread? > > Thanks, Joel > > On Nov 29, 2005, at 9:20 AM, Simon Marlow wrote: > >> Interestingly, GHC already has a timeout thread - the I/O manager >> thread handles threadDelay too. It wouldn't be too hard to adapt it >> to do STM timeouts too, with a function like >> >> registerTimeout :: Int -> STM (TVar Bool) >> >> and you wait for your timeout by waiting for the TVar to contain >> True.

3 4

Existentially-quantified constructors, Eq and Show
by Joel Reymont 12 Dec '05

12 Dec '05

Folks, Is there a less verbose way of doing this: data State a = Start | Stop | (Show a, Eq a) => State a instance Eq a => Eq (State a) where (State a) == (State b) = a == b Start == Start = True Stop == Stop = True instance Show a => Show (State a) where show (State a) = show a show Start = "Start" show Stop = "Stop" Thanks, Joel -- http://wagerlabs.com/

9 18

Re: [Haskell-cafe] Opening the same file multiple times
by Donn Cave 12 Dec '05

12 Dec '05

Quoth Einar Karttunen <ekarttun(a)cs.helsinki.fi>: | It seems that opening the same file multiple times (one writer | and multiple readers) is not supported at least on *nix with | GHC. I want to use one Handle to use append data till the | end of the file while other Handles perform random access | IO with seeks on the file. How is it not supported? What happens with something like this module Main (main) where import IO (openFile, IOMode(..), SeekMode(..), hPutStr, hSeek, hGetLine) import System (getArgs) main = do af <- openFile "z" AppendMode sf <- openFile "z" ReadMode hPutStr af "append this line\n" hSeek sf AbsoluteSeek 40 hGetLine sf >>= print hPutStr af "append this line\n" hSeek sf AbsoluteSeek 60 hGetLine sf >>= print (It works for me, with hugs on a more or less UNIX-like platform.) Donn Cave, donn(a)drizzle.com | Sharing the same Handle for all the threads is not possible | since they perform seeks and may thus mess each other up. | Hiding the Handle behind a mutex would limit concurrency | more than I like. | | Thus I wanted to open multiple Handles to the file, but | this seems quite hard. My best guess is to create a function | like: | | #ifdef mingw32_HOST_OS | openUnlocked fn mode = openBinaryFile fn mode | #else | openUnlocked fn mode = withMVar mutex $ do | h <- openBinaryFile fn mode | fd <- handleToFd h | unlockFile $ fromIntegral fd | return h | | {-# NOINLINE mutes #-} | mutex = unsafePerformIO $ newMVar () | #endif | | Is there really no simpler solution?

2 1

Tail-call optimization
by Joel Reymont 12 Dec '05

12 Dec '05

I always wandered, does ghc do tail-call optimization? Would it optimize the two variants of the function below or just the first one? --- Proper? writeLoop :: (Event a -> IO ()) -> Handle -> (SSL, BIO, BIO) -> IO () writeLoop post h ssl = do handle (\e -> post $ NetworkError e) $ do cmd <- read h ssl post $! Cmd $! cmd writeLoop post h ssl --- Bad? writeLoop :: (Event a -> IO ()) -> Handle -> (SSL, BIO, BIO) -> IO () writeLoop post h ssl = do handle (\e -> post $ NetworkError e) $ do cmd <- read h ssl post $! Cmd $! cmd writeLoop post h ssl Thanks, Joel -- http://wagerlabs.com/

4 5