Re: [Haskell-cafe] Re: sendfile leaking descriptors on Linux?
Excerpts from Bardur Arantsson's message of Tue Feb 16 23:48:14 +0200 2010: This cannot be fixed in the sendfile library, it is a feature of TCP that connections may linger for a long time unless explicit timeouts are used. The problem is that the sendfile library *doesn't* wake up when the connection is terminated (because of threadWaitWrite) -- it doesn't matter what the timeout is. Even server code without sendfile has the same issue since all writing to sockets ends up using threadWaitWrite. System.Timeout.timeout terminates a threadWaitWrite using asynchronous exceptions. If you want to detect dead sockets somewhat reliably without a timeout then there is SO_KEEPALIVE combined with polling SO_ERROR every few minutes. - Taru Karttunen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linear programming in Haskell
I think that GSL does not include linear programming solvers, but in the GSL home page there is a reference to the GLPK package: http://www.gnu.org/software/glpk/glpk.html I have not used it, but it would be very nice to have a simple Haskell interface to GLPK (or other similar library) in hmatrix or as a separate package. I will take a look at this. Alberto Daniel Peebles wrote: As far as I can see, you'd use that for systems of linear /equalities/, but for systems of linear /inequalities/ with a linear objective function, it's not suitable. I may be wrong though :) On Tue, Feb 16, 2010 at 3:37 PM, Felipe Lessa felipe.le...@gmail.com mailto:felipe.le...@gmail.com wrote: On Tue, Feb 16, 2010 at 03:12:53PM -0500, Daniel Peebles wrote: How would you use hmatrix? By linear programming I assume he means systems of linear inequalities, as typically solved by the simplex algorithm. I too am interested in this question (and the more general one of nonlinear optimization)! I have never used this part of hmatrix, but does Numeric.LinearAlgebra satisfy your needs? In particular, see linearSolve[1] and linearSolveR[2]. [1] http://hackage.haskell.org/packages/archive/hmatrix/0.8.3.1/doc/html/Numeric-LinearAlgebra-Algorithms.html#v%3AlinearSolve [2] http://hackage.haskell.org/packages/archive/hmatrix/0.8.3.1/doc/html/Numeric-LinearAlgebra-LAPACK.html#v%3AlinearSolveR HTH, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: concurrent-extra
2010/2/16 Neil Brown nc...@kent.ac.uk: I had a look at the code for Event (both versions) and Lock (but not the others just yet) and it seemed fine. If you do lots of calls to waitTimeout before a set you will accumulate old locks in the list, but that won't cause any error that I can see, so it would only be a problem in pathological cases. I think I can fix the garbage locks on waitTimeout by tupling each lock with the ThreadId of the thread that created it. When a timeout occurs I can then simply remove the unnecessary lock from the list. The extra overhead would be the construction of a tuple and acquiring a ThreadId each time you wait for an event. I'm not sure there is a good way to test MVar algorithms. One way to do it (which the Concurrent Haskell Debugger did online, IIRC: http://www.informatik.uni-kiel.de/~fhu/chd/) is to reimplement IO to explore different interleavings of the various MVar calls to look for deadlocks. If you're testing STM, generally you can look to capture invariants of your transactions and check that they hold after each transaction (e.g. that if the state is Set, there shouldn't be any locks waiting with an event). Interesting. It reminds me of Wouter Swierstra's recent paper Beauty in the Beast: http://www.cs.nott.ac.uk/~txa/publ/beast.pdf Thanks, Roel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Example for RVarT?
Hello folks, is there an example (simpe or not) for the use of Data.Random.RVarT with an underlying monad other than Identity, e.g. StateT, ReaderT etc.? Thx Torsten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RFC: concurrent-extra
2010/2/16 Simon Marlow marlo...@gmail.com: You might want to take a look at the concurrency part of the GHC test suite: http://darcs.haskell.org/testsuite/tests/ghc-regress/concurrent/should_run/ Not that we've really solved the problem you're talking about, but you might get some ideas. The method of testing appears to be similar to what I do now using unit tests. But the contents of the tests are interesting. I'll see if they are applicable to our primitives. Thanks, Roel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: concurrent-extra
Roel van Dijk wrote: 2010/2/16 Neil Brown nc...@kent.ac.uk: I had a look at the code for Event (both versions) and Lock (but not the others just yet) and it seemed fine. If you do lots of calls to waitTimeout before a set you will accumulate old locks in the list, but that won't cause any error that I can see, so it would only be a problem in pathological cases. I think I can fix the garbage locks on waitTimeout by tupling each lock with the ThreadId of the thread that created it. When a timeout occurs I can then simply remove the unnecessary lock from the list. The extra overhead would be the construction of a tuple and acquiring a ThreadId each time you wait for an event. You don't need to do use ThreadId: MVar has an Eq instance, so you could make your Lock type derive an Eq instance, and then you can just compare the Locks to remove it after the timeout occurs (e.g. using delete to take it out of the list; it should be quite near the head of the list anyway). In fact, you may as well make most of your types derive an Eq instance where possible, as this can be useful sometimes. Thanks, Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: concurrent-extra
2010/2/17 Neil Brown nc...@kent.ac.uk: You don't need to do use ThreadId: MVar has an Eq instance, so you could make your Lock type derive an Eq instance, and then you can just compare the Locks to remove it after the timeout occurs (e.g. using delete to take it out of the list; it should be quite near the head of the list anyway). In fact, you may as well make most of your types derive an Eq instance where possible, as this can be useful sometimes. Now I am wondering why I didn't think of that before. It's an elegant solution. Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threading and FFI
I've also discovered something interesting: when I link with the 'threaded' runtime, but let the program use only one core (with '+RTS -N1'), the problem disappears. How comes? The whole thing remains a mystery, because I think what I'm trying to do is quite common... Yves Parès wrote: There is a minimal code which produces this issue: http://old.nabble.com/file/p27613138/func.c func.c http://old.nabble.com/file/p27613138/main.hs main.hs Yves Parès wrote: Well I tried both 'unsafe' and 'safe', and actually I saw no difference... Even with 'safe', I see a huge difference between calling a C function which sleeps and another which doesn't. When there is a sleep, the other thread is really slower (it just prints numbers, and I look at which pace they're displayed). - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27621580.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GUI (was: Re: [Haskell-cafe] DLL on Windows)
You're probably correct about the dependencies. I have never tried to compile wxHaskell against GHC 6.12.1 I'm waiting for Haskell Platform to be released to make the required changes since (working primarily on Windows) I just don't have time to create a complete GHC 6.12 installation with most of the HP libraries (some of which are a pain to get working on Windows). wxHaskell will support GHC 6.12.x within a couple of days of release of a suitable Haskell Platform. Regards Jeremy On Tue, 16 Feb 2010 17:55 -0800, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: On Tue, Feb 16, 2010 at 3:48 PM, Henk-Jan van Tuyl hjgt...@chello.nl wrote: On Tue, 16 Feb 2010 18:57:20 +0100, Neil Mitchell ndmitch...@gmail.com wrote: I used to recommend Gtk2hs over wxHaskell for GUI development as there was always a version that worked on Windows with the latest GHC release. I think I might have to switch back to recommending C# for GUI development... The latest revision of wxHaskell can be compiled relatively easy, so that wxHaskell can be used immediately for the latest version of GHC. Exciting allegation, but it doesn't quite check out with GHC 6.12.1 + cabal 1.8.0.2 and cabal-install 0.8 (see below). I would expect this issue to be easily resolved by specifying containers = 0.3.* in the wxdirect package, but cabal is misbehaving (for me) and stating wxdirect needs reinstalled with a supposedly newer version of containers, 0.2.0.1. Thomas [to...@mavlo ~]$ cabal install wx Resolving dependencies... Downloading containers-0.2.0.1... Configuring containers-0.2.0.1... Preprocessing library containers-0.2.0.1... Building containers-0.2.0.1... Data/IntMap.hs:182:7: Could not find module `Data.Data': It is a member of the hidden package `base'. Perhaps you need to add `base' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. cabal: Error: some packages failed to install: containers-0.2.0.1 failed during the building phase. The exception was: ExitFailure 1 wx-0.12.1.2 depends on containers-0.2.0.1 which failed to install. wxcore-0.12.1.2 depends on containers-0.2.0.1 which failed to install. wxdirect-0.12.1.1 depends on containers-0.2.0.1 which failed to install. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Jeremy O'Donoghue jeremy.odonog...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Implementing unionAll
Leon Smith wrote: Heinrich Apfelmus wrote: I see no obvious deficiencies. :) Personally, I'd probably structure it like http://www.haskell.org/haskellwiki/Prime_numbers#Implicit_Heap This variant, based on the wiki article, is cleaner, slightly simpler, appears to be just as fast, and allocates slightly less memory: import GHC.Exts(inline) import Data.List.Ordered(unionBy) union' :: People Int - People Int - People Int union' (VIP x xt) ys= VIP x (union' xt ys) union' (Crowd xs) (Crowd ys)= Crowd (inline unionBy compare xs ys) union' xs@(Crowd (x:xt)) ys@(VIP y yt) = case compare x y of LT - VIP x (union' (Crowd xt) ys) EQ - VIP x (union' (Crowd xt) yt) GT - VIP y (union' xs yt) foldTree :: (a - a - a) - [a] - a foldTree f xs = case xs of [] - [] xs - loop xs where loop [x]= x loop (x:xs) = x `f` loop (pairs xs) pairs (x:y:ys) = f x y : pairs ys pairs xs = xs unions xss = serve $ inline foldTree union' [ VIP x (Crowd xs) | (x:xs) - xss ] where serve (VIP x xs) = x:serve xs serve (Crowd xs) = xs One of the differences is that I started with a slightly different foldTree, one that was taken directly from Data.List.sort. The only problem is that it has the same problem as I mentioned: unionAll [[1,2],[1,2]] == [1,1,2] whereas unionAll is intended to be a generalization of foldr union [] to an infinite number of lists, and should thus return [1,2]. But I should be able to fix this without much difficulty. Ah, I meant to use the union' from your previous message, but I think that doesn't work because it doesn't have the crucial property that the case union (VIP x xs) ys = ... does not pattern match on the second argument. The easiest solution is simply to define unionAll = nub . mergeAll where -- specialized definition of nub nub = map head . groupBy (==) But you're probably concerned that filtering for duplicates afterwards will be less efficient. After all, the (implicit) tree built by mergeAll might needlessly compare a lot of equal elements. Fortunately, it is straightforward to fuse nub into the tree merging: nub . serve . foldTree union' = serve . nubP . foldTree union' = serve . foldTree (nub' . union') with appropriate definitions of nubP and nub' . In particular, the definition -- remove duplicate VIPs nub' (Crowd xs) = Crowd xs nub' (VIP x xs) = VIP x (guard x xs) where guard x (VIP y ys) | x == y= nub' ys | otherwise = VIP y (guard y ys) guard x (Crowd (y:ys)) | x == y= Crowd ys | otherwise = Crowd (y:ys) takes advantage of the facts that * the left and right arguments of union' can now be assumed to not contain duplicates * crowds do not contain duplicates thanks to the call to unionBy Whether nub' saves more comparisons than it introduces is another question. If you want, you can probably fuse nub' and union' as well, but I guess the result won't be pretty. Incidentally, I tried implementing something like implicit heaps once upon a time; but it had a severe performance problem, taking a few minutes to produce 20-30 elements.I didn't have a pressing reason to figure out why though, and didn't pursue it further. Yeah, they're tricky to get right. One pattern match too strict and it's sucked into a black hole, two pattern matches too lazy and it will leak space like the big bang. :) Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda's
Hi I agree with the sentiments below. I subscribe to particular lists because of their specialism. The URL referred to had a tenuous Haskell connection, and definitely not work the bandwidth consumed. I'm having a difficult enough time trying to master Haskell without that form of diversion. Enough said. On Thu, 2009-12-31 at 10:35 +0200, Michael Snoyman wrote: Some of us prefer not to look at that kind of material. I'd appreciate if, in the future, you could either refrain from sending such links or making it clear that they contain objectionable content. Thanks, Michael On Thu, Dec 31, 2009 at 1:15 AM, Henk-Jan van Tuyl hjgt...@chello.nl wrote: I love lambda's: http://hawtness.com/2009/12/30/wtf-girl-photo-more-reasons-why-half-life-is-awesome/ -- Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: concurrent-extra-0.1
Hello, We would like to announce the release of concurrent-extra [1]. A library which offers a few extra synchronization primitives. These primitives are found in the standard libraries of languages like Java and Python, but not in Haskell. Quick overview: * Lock: Enforce exclusive access to a resource. Also known as a mutex or a binary semaphore. * RLock: A lock which can be acquired multiple times by the same thread. Also known as a reentrant mutex. * Event: Wake multiple threads by signaling an event. Includes both pessimistic and optimistic versions. * ReadWriteLock: Multiple-reader, single-writer locks. Used to protect shared resources which may be concurrently read, but only sequentially written. * ReadWriteVar: Concurrent read, sequential write variables. Plug Play: cabal install concurrent-extra Darcs: darcs get http://code.haskell.org/~roelvandijk/code/concurrent-extra/ Thanks to Neil Brown and Simon Marlow for an initial review. Comments are still more than welcome! Regards, Roel Bas van Dijk [1] http://hackage.haskell.org/package/concurrent-extra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: concurrent-extra-0.1
Hello, Thanks for the release! On Wed, Feb 17, 2010 at 03:10:38PM +0100, Roel van Dijk wrote: * RLock: A lock which can be acquired multiple times by the same thread. Also known as a reentrant mutex. In acquire (l. 111), if the lock was already acquired it goes by | otherwise → do putMVar mv mb Lock.acquire lock So it puts back the information about the owner of the RLock and waits for its release in the normal Lock. And then... nothing? Shouldn't it need to put into mv information about itself? In release (l. 142) Nothing is put into mv then do Lock.release lock putMVar mv Nothing Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Heterogeneous Data Structures - Nested Pairs and functional references
Hi Alex, this looks very very interesting, gimme some time to figure it. I hope you'll take questions later ... Günther Am 16.02.10 22:34, schrieb Alexander Solla: On Feb 16, 2010, at 12:48 PM, Alexander Solla wrote: (Accumulator String)s are (Accumulator value)s for any value. So you can build things like: Sorry, I made a typo. I meant StringAccumulator Strings are Accumulator values for any value. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pointfree composition for higher arity
I find myself often writing this pattern: someFun x y z = ... fun y z = runFun $ someFun someDefault y z or, alternatively: fun y = runFun . someFun someDefault y The second option approaches the ideal pointfreeness (or pointlessness if you prefer), but I'd like to go farther: (...) :: (c - d) - (a - b - c) - a - b - d (...) f g x y = f (g x y) infixr 9 ... fun = runFun ... someFun someDefault There, that's better. More points for fewer points (which means I should really change the name from fun to pun). Does anybody else care about this? What are some alternative solutions? I'd love to have something like this available in the Prelude or a library. (I have no strong feelings about the particular operator.) Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree composition for higher arity
Sean Leather wrote: I find myself often writing this pattern: someFun x y z = ... fun y z = runFun $ someFun someDefault y z or, alternatively: fun y = runFun . someFun someDefault y I very often write this too (wanting function composition, but with a two-argument function on the right hand side). The trick I picked up from somewhere is to do: fun = (runFun .) . someFun someDefault I'm not too keen on that, as it seems clumsy. I often end up writing the operator that you describe, but have never settled on a consistent name (since the obvious one to me, (..), is taken). Thanks, Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree composition for higher arity
That signature is the `oo` specs combinator in Data.Aviary: fun = runFun `oo` someFun someDefault -md begin Sean Leather quotation: I find myself often writing this pattern: someFun x y z = ... fun y z = runFun $ someFun someDefault y z or, alternatively: fun y = runFun . someFun someDefault y The second option approaches the ideal pointfreeness (or pointlessness if you prefer), but I'd like to go farther: (...) :: (c - d) - (a - b - c) - a - b - d (...) f g x y = f (g x y) infixr 9 ... fun = runFun ... someFun someDefault There, that's better. More points for fewer points (which means I should really change the name from fun to pun). Does anybody else care about this? What are some alternative solutions? I'd love to have something like this available in the Prelude or a library. (I have no strong feelings about the particular operator.) Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The Related monad and constant values in type classes
Hi,
This literate haskell file was intended to be a quick question about a
problem i have been pondering, but it developed into a short
presentation instead. What i want to know is if there is already
something like this (and suggestions for improvement of course).
{-#LANGUAGE GeneralizedNewtypeDeriving#-}
Sometimes i find myself needing to associate a constant with a type
or, more precisely, with a type class instance. Something like this
would be nice:
class Sized a where
size :: Int
instance Sized Int where
size = 32
Of course this will not work since there is no way of knowing which
instance i refer to when i use size. A common work-around is to use
a dummy parameter:
class SizedDummy a where
sizeDummy :: a - Int
instance SizedDummy Int where
sizeDummy = const 32
The size function is typically passed an undefined value. This is not
very pretty, and somewhat unsafe. Another workaround is to define a
newtype with a type parameter.
newtype SizeOf a = MkSize {toInt :: Int}
class SizedNewType a where
sizeNewType :: SizeOf a
instance SizedNewType Int where
sizeNewType = MkSize 32
If we want the size of a pair to be the sum of it's components,
something like this is needed:
instance (SizedNewType a, SizedNewType b) = SizedNewType (a,b) where
sizeNewType = sizeNewType' sizeNewType sizeNewType where
sizeNewType' :: SizeOf a - SizeOf b - SizeOf (a,b)
sizeNewType' a b = MkSize $ toInt a + toInt b
This is way to much code say that size = size a + size b. A more
general solution can be achieved by making Int another type variable
of SizeOf. I call the resulting type Related:
newtype Related a b = Related {unrelated :: b} deriving
(Eq,Ord,Show,Read,Bounded,Enum,Fractional,Num,
Real,Integral,RealFrac,Floating,RealFloat)
This type is highly reusable and the GeneralizedNewtypeDeriving
language extension is very practical (although the instances could be
written manually). It can also be used as an Identity monad:
instance Functor (Related a) where
fmap f (Related a) = Related $ f a
instance Monad (Related a) where
return = Related
(Related a) = f = f a
This allows the Sized class and instances to be specified in a slim
fashion using a familiar monadic interface:
class Sized a where
size :: Related a Int
instance Sized Int where
size = return 32
instance (Sized a, Sized b) = Sized (a,b) where
size = do
a - return size :: Sized a = Related (a,b) (Related a Int)
b - return size :: Sized b = Related (a,b) (Related b Int)
return $ unrelated a + unrelated b
This still requires a lot of type signatures, some additional magic is
required. It is possible to write general versions of the type
signatures above, which allows the following instance definition for
(,,):
instance (Sized a, Sized b, Sized c) = Sized (a,b,c) where
size = do
a - on3 size
b - on2 size
c - on1 size
return $ a + b + c
With the derivation of Num, this can be done even more compact:
instance (Sized a, Sized b, Sized c, Sized d) = Sized (a,b,c,d) where
size = on1 size + on2 size + on3 size + on4 size
The code for the onN functions:
rerelate :: Related a b - Related c b
rerelate = return . unrelated
on1 :: Related a v - Related (x a) v
on1 = rerelate
on2 :: Related a v - Related (x a x0) v
on2 = rerelate
on3 :: Related a v - Related (x a x0 x1) v
on3 = rerelate
on4 :: Related a v - Related (x a x0 x1 x2) v
on4 = rerelate
Regards,
Jonas Almström Duregård
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree composition for higher arity
On 17 February 2010 15:41, Mike Dillon m...@embody.org wrote: That signature is the `oo` specs combinator in Data.Aviary: Hi Mike Thanks - indeed, I was just looking up the thread that covered them a month or two ago: http://www.haskell.org/pipermail/haskell-cafe/2009-December/071392.html I wouldn't recommend writing code that depends on Data.Aviary, but some of the combinators are often worth copy/pasting out of it. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree composition for higher arity
Am Mittwoch 17 Februar 2010 16:31:16 schrieb Sean Leather: I find myself often writing this pattern: someFun x y z = ... fun y z = runFun $ someFun someDefault y z or, alternatively: fun y = runFun . someFun someDefault y The second option approaches the ideal pointfreeness (or pointlessness if you prefer), but I'd like to go farther: (...) :: (c - d) - (a - b - c) - a - b - d (...) f g x y = f (g x y) (...) = (.) . (.) infixr 9 ... fun = runFun ... someFun someDefault There, that's better. More points for fewer points (which means I should really change the name from fun to pun). Does anybody else care about this? What are some alternative solutions? o = (.) oo = (.) . (.) ooo = (.) . (.) . (.) -- etc. runFun `oo` someFun someDefault I've also seen (.:) = (.) . (.) runFun .: someFun someDefault I don't particularly like (...), it's too much like an ellipsis (and bad to count if you continue on that route), I prefer the 'spectacles' or (∘) = (.) (∘∘) = (.) . (.) I'd love to have something like this available in the Prelude or a library. (I have no strong feelings about the particular operator.) Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree composition for higher arity
begin Stephen Tetley quotation: On 17 February 2010 15:41, Mike Dillon m...@embody.org wrote: That signature is the `oo` specs combinator in Data.Aviary: Hi Mike Thanks - indeed, I was just looking up the thread that covered them a month or two ago: http://www.haskell.org/pipermail/haskell-cafe/2009-December/071392.html I wouldn't recommend writing code that depends on Data.Aviary, but some of the combinators are often worth copy/pasting out of it. Are you kidding me? I love writing code like this: o = bunting bunting cardinal thrush blackbird :) -md ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: concurrent-extra-0.1
On Wed, Feb 17, 2010 at 3:27 PM, Felipe Lessa felipe.le...@gmail.com wrote: In acquire (l. 111), if the lock was already acquired it goes by | otherwise → do putMVar mv mb Lock.acquire lock So it puts back the information about the owner of the RLock and waits for its release in the normal Lock. And then... nothing? Shouldn't it need to put into mv information about itself? Well spotted! In order to fix this we changed the structure of an RLock a bit. The inner lock isn't contained in a Maybe anymore but directly in the MVar. So now there is only 1 Lock associated with an RLock. This makes reasoning about the control flow a bit simpler. We also added a test case which fails on the original code but succeeds with the new version. In release (l. 142) Nothing is put into mv then do Lock.release lock putMVar mv Nothing I'm not sure if that was a bug in the original. In the new version we put the lock back inside the MVar. Current version: http://hackage.haskell.org/package/concurrent-extra-0.1.0.1 Thanks, Roel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree composition for higher arity
On 17 February 2010 16:05, Mike Dillon m...@embody.org wrote: ... Are you kidding me? I love writing code like this: o = bunting bunting cardinal thrush blackbird :) Hi Mike Thanks! - it took me a surprising amount of time to get from this (where I cheated and used an online 'combinator calculator'): psi :: (b - b - c) - (a - b) - a - a - c psi = c (b s (b (b c) (b (b (b b)) (c (b b (b b i)) (c (b b i) i) (c (b b i) i) where c = cardinal b = bluebird s = starling i = idiot ... to this: psi :: (b - b - c) - (a - b) - a - a - c psi = cardinal (bluebird starling (bluebird cardinalstar dovekie)) applicator ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
The easiest solution is simply to define unionAll = nub . mergeAll where -- specialized definition of nub nub = map head . groupBy (==) Talking about the easiest solution, I guess this is a quite easy way of defining unionAll as well: http://gist.github.com/306782 I, of course, do not claim that it is more efficient or better. But I don't think it'd be rubbish :) -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: sendfile leaking descriptors on Linux?
On Wed, Feb 17, 2010 at 2:36 AM, Taru Karttunen tar...@taruti.net wrote: Excerpts from Bardur Arantsson's message of Tue Feb 16 23:48:14 +0200 2010: This cannot be fixed in the sendfile library, it is a feature of TCP that connections may linger for a long time unless explicit timeouts are used. The problem is that the sendfile library *doesn't* wake up when the connection is terminated (because of threadWaitWrite) -- it doesn't matter what the timeout is. Even server code without sendfile has the same issue since all writing to sockets ends up using threadWaitWrite. Right, this is my concern -- I want to make sure that all of happstack is fixed, not just sendfile. System.Timeout.timeout terminates a threadWaitWrite using asynchronous exceptions. So for sendfile, instead of threadWaitWrite we could do: r - timeout (60 * 10^6) threadWaitWrite case r of Nothing - ... -- timed out (Just ()) - ... -- keep going It seems tricky to use timeout at a higher level in the code, because some requests may take a very long time to finish. For example, when serving a long video, or streaming music it could be hours or days before the IO request finishes. If you want to detect dead sockets somewhat reliably without a timeout then there is SO_KEEPALIVE combined with polling SO_ERROR every few minutes. This approach sounds promising because it seems like it could be incorporated into the guts of happstack-server. The timeout period could be a Config option with a reasonable default. I would be surprised if *any* happstack programs today are handling this correctly, so updating the core to do something reasonable would be a big improvement... And if someone has a special need where it is not ok, they can just change the config to use an infinite timeout... Does that sound like the right fix to you? (Obviously, if people are using sendfile with something other than happstack, it does not help them, but it sounds like trying to fix things in sendfile is misguided anyway.) - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
Am Mittwoch 17 Februar 2010 17:46:38 schrieb Ozgur Akgun: The easiest solution is simply to define unionAll = nub . mergeAll where -- specialized definition of nub nub = map head . groupBy (==) Talking about the easiest solution, I guess this is a quite easy way of defining unionAll as well: http://gist.github.com/306782 I, of course, do not claim that it is more efficient or better. But I don't think it'd be rubbish :) let next = minimum (map head xs') doesn't work if you have infinitely many lists :( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CURL and threads
Hello, all! Can somebody please explain, what is the best way of using CURL with several threads? I wrote simple client, which tries to authenticate against HTTP server. With running this client, it starts to eat memory insanely (and I know this code is far, far away of even being close to be called good one ) = module NTLMTest where import System.IO import Network.Curl import Control.Concurrent import Control.Concurrent.Chan type ResponseState = Either Bool String type RespChannel = Chan ResponseState delay = 500 * 1000 isResponseOk :: String - CurlResponse - ResponseState isResponseOk username response = case respCurlCode response of CurlOK - Left True _ - Right $ username ++ = ++ respStatusLine response ++ :: ++ (show . respStatus $ response) checkAuthResponse :: RespChannel - String - String - String - IO () checkAuthResponse state user passwd url = do response - curlGetResponse_ url [CurlHttpAuth [HttpAuthAny], CurlUserPwd $ user ++ : ++ passwd] writeChan state $ isResponseOk user response threadDelay $ delay runHTTPThread :: RespChannel - (String,String) - IO () runHTTPThread state (user,passwd) = checkAuthResponse state user passwd url url = http://localhost:8082/; credentials = map (\i - (user ++ show i,123456)) [1..21] main = withCurlDo $ do chan - newChan :: IO (RespChannel) mapM_ ( \cred - forkIO $ runHTTPThread chan cred ) credentials dumpChannel chan $ length credentials main where dumpChannel :: RespChannel - Int - IO () dumpChannel _chan n | n == 0= return () | otherwise = dostate - readChan _chan case state of (Left _) - return () --putStrLn OK (Right err) - putStrLn err dumpChannel _chan $ n-1 = If I get rid of forkIO - it stops at 40-50 megabytes and don't raise memory usage anymore. Also, I noticed that (either because of buffering, or may be something else) results are appearing on console much slower than if I simply use wget with looping in shell script. JMeter also reports awesome speed, so server can authenticate tens of concurrent users per second (thus it's not server or connection bandwidth issue). Hopefully, someone could help me in overcoming my ignorance :) -- Eugene N Dzhurinsky pgpZlHfRhTKWZ.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
Ooops I thought the inner lists are possibly of infinite size. On 17 February 2010 17:16, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Mittwoch 17 Februar 2010 17:46:38 schrieb Ozgur Akgun: The easiest solution is simply to define unionAll = nub . mergeAll where -- specialized definition of nub nub = map head . groupBy (==) Talking about the easiest solution, I guess this is a quite easy way of defining unionAll as well: http://gist.github.com/306782 I, of course, do not claim that it is more efficient or better. But I don't think it'd be rubbish :) let next = minimum (map head xs') doesn't work if you have infinitely many lists :( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
Am Mittwoch 17 Februar 2010 18:59:42 schrieb Ozgur Akgun: Ooops I thought the inner lists are possibly of infinite size. Both, I think. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: concurrent-extra-0.1
On Wed, Feb 17, 2010 at 05:11:45PM +0100, Roel van Dijk wrote: On Wed, Feb 17, 2010 at 3:27 PM, Felipe Lessa felipe.le...@gmail.com wrote: In release (l. 142) Nothing is put into mv then do Lock.release lock putMVar mv Nothing I'm not sure if that was a bug in the original. In the new version we put the lock back inside the MVar. I think it was workable, I've referenced the code just to make the e-mail more self-contained. That Nothing was going to stay after the inner Lock was acquired. :) Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: sendfile leaking descriptors on Linux?
Jeremy Shaw wrote: On Wed, Feb 17, 2010 at 2:36 AM, Taru Karttunen tar...@taruti.net wrote: So for sendfile, instead of threadWaitWrite we could do: r - timeout (60 * 10^6) threadWaitWrite case r of Nothing - ... -- timed out (Just ()) - ... -- keep going For sendfile, a timeout of 1 second would probably be fine. The *ONLY* purpose of threadWaitWrite in the sendfile code is to avoid busy-waiting on EAGAIN from the native sendfile. What would work is, instead of using threadWaitRead (as in the code you supplied) to simply have a 1 second timeout which causes the loop to call the native sendfile again. Native sendfile *will* fail with an error code if the socket has been disconnected. With that in place dead threads waiting on threadWaitWrite will only linger at most 1 second before discovering the disconnect. Not ideal, but a lot better than the current situation. Does that sound like the right fix to you? [--snip--] (Obviously, if people are using sendfile with something other than happstack, it does not help them, but it sounds like trying to fix things in sendfile is misguided anyway.) How so? As a user I expect sendfile to work and not semi-randomly block threads indefinitely. Cheers, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Related monad and constant values in type classes
What i want to know is if there is already something like this (and suggestions for improvement of course). ... Sometimes i find myself needing to associate a constant with a type or, more precisely, with a type class instance. I'm not sure if this is what you're looking for, but it seems related. Oleg Kiselyov, Chung-chieh Shan. Functional pearl: Implicit configurations-or, type classes reflect the values of types, in Haskell 2004. ACM, 2004, pp. 33-44. http://www.citeulike.org/user/spl/article/313800 Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CURL and threads
On Wed, Feb 17, 2010 at 07:34:07PM +0200, Eugene Dzhurinsky wrote: Hopefully, someone could help me in overcoming my ignorance :) I realized that I can share the same Chan instance over all invocations in main, and wrap internal function into withCurlDo to ensure only one IO action gets executed with this library. Finally I've come with the following code, which however still has some memory leaks. May be someone will get an idea what's wrong below? = module NTLMTest where import System.IO import Network.Curl import Control.Concurrent import Control.Concurrent.Chan type ResponseState = Either Bool String type RespChannel = Chan ResponseState delay = 500 * 1000 isResponseOk :: String - CurlResponse - ResponseState isResponseOk username response = case respCurlCode response of CurlOK - Left True _ - Right $ username ++ = ++ respStatusLine response ++ :: ++ (show . respStatus $ response) checkAuthResponse :: RespChannel - String - String - String - IO () checkAuthResponse state user passwd url = do response - curlGetResponse_ url [CurlHttpAuth [HttpAuthAny], CurlUserPwd $ user ++ : ++ passwd] writeChan state $ isResponseOk user response threadDelay $ delay runHTTPThread :: RespChannel - (String,String) - IO () runHTTPThread state (user,passwd) = checkAuthResponse state user passwd url url = http://localhost:8082/; credentials = map (\i - (user ++ show i,123456)) [1..21] main = do chan - newChan :: IO (RespChannel) withCurlDo $ invokeThreads chan where invokeThreads chan = do mapM_ ( \cred - forkIO $ runHTTPThread chan cred ) credentials dumpChannel chan $ length credentials invokeThreads chan dumpChannel :: RespChannel - Int - IO () dumpChannel _chan n | n == 0= return () | otherwise = dostate - readChan _chan case state of (Left _) - return () --putStrLn OK (Right err) - putStrLn err dumpChannel _chan $ n-1 = Thank you in advance! -- Eugene Dzhurinsky pgpKh7SMOSfg4.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linear programming in Haskell
As far as I can see, you'd use that for systems of linear equalities, but for systems of linear inequalities with a linear objective function, it's not suitable. I may be wrong though :) There's a linear [1] reduction from one problem to the other and vice versa. [1] The transformation itself is a linear function, and it takes O(n) time, too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree composition for higher arity
On Wed, Feb 17, 2010 at 16:48, Stephen Tetley wrote: On 17 February 2010 15:41, Mike Dillon m...@embody.org wrote: That signature is the `oo` specs combinator in Data.Aviary: Nice! I wouldn't recommend writing code that depends on Data.Aviary, but some of the combinators are often worth copy/pasting out of it. On the contrary, I think the specs combinators and perhaps others in Data.Aviary (probably not Data.Aviary.*) have potential. We could even generalize oo and the others to categories and add it to Control.Category (which is, after all, looking rather empty). import Control.Category import Prelude hiding ((.)) -- oo :: (c - d) - (a - b - c) - a - b - d oo :: (Category cat) = cat c d - (a - cat b c) - a - cat b d oo = (.) . (.) -- ooo :: (d - e) - (a - b - c - d) - a - b - c - e ooo :: (Category cat) = cat d e - (a - b - cat c d) - a - b - cat c e ooo = (.) . (.) . (.) -- :: (e - f) - (a - b - c - d - e) - a - b - c - d - f :: (Category cat) = cat e f - (a - b - c - cat d e) - a - b - c - cat d f = (.) . (.) . (.) . (.) Is it necessary? Maybe not. I'm guessing that the names oo, etc. do not have a commonly accepted meaning, so I like them. I'd like to have a module (e.g. Control.Pointfree) containing these and other useful general combinators from the community. Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: sendfile leaking descriptors on Linux?
On Wed, Feb 17, 2010 at 1:27 PM, Bardur Arantsson s...@scientician.netwrote: (Obviously, if people are using sendfile with something other than happstack, it does not help them, but it sounds like trying to fix things in sendfile is misguided anyway.) How so? As a user I expect sendfile to work and not semi-randomly block threads indefinitely. Because it only addresses *one* case when this type of blocking can happen. Shouldn't hPut and friends also block indefinitely since they also use threadWaitWrite? If so, what good is just fixing sendfile, when all other network I/O will still block indefinitely? If things are 'fixed' at a higher-level, by using SO_KEEPALIVE, then does sendfile really need a hack to deal with it? With your proposed fix, if the user unplugs the network cable, then won't you get an polling loop that never terminates? That doesn't sound any better than the current situation.. You said that you have not seen this issue when using the code that uses hPut, only the code that uses sendfile(). But my research indicates that we *should* see the error. So, I am not very comfortable fixing just sendfile and ignoring the fact that all network I/O might be borked.. I am also not 100% pleased by the SO_KEEPALIVE solution. There are really two errors which can occur: 1. the remote end drops the connection in such a manner that we immediately get notified of it by seeing that a read select() on the socket is successful but there are 0 bytes available to read. This happens because the remote end sent a notification to us that they have terminated the connection. 2. the remote end drops off the network (for example, the network cable is disconnected). In this case, we will not get any notification via read select(), because the remote server is not there to send the notification. The only solution is to eventually timeout. By using a timeout to handle #2, we implicitly handle #1, but in a very untimely manner. Ideally, we would like to handle both these cases separately. In case #1, we know immediately, that the connection is dead, and can therefore clean things up. With case #2, the remote client might actually come back online, (someone plugs the cable back in), and the transfer resumes. Perhaps in some applications we want infinite timeouts for case #2. That does not mean we do not want case #1 handled. However, I do not really see a good way of handle #1 right now that works for all network code, not just sendfile. The issue seems to be that select() was designed as a way to *avoid* using threads. There seems to be the assumption in the network code that you are going to do a select on the read and write aspects of the socket. When the select returns you will then look at what happened, and take the correct action. But, in Haskell, we are using multiple threads. So the code that is looking to read data and the code that is looking to write data don't really know about each other. So even if the read thread detects the closed socket, it has no idea that some other thread needs to be killed. so, what to do? Perhaps it is wrong to use a socket in more than one thread? Obviously, having multiple threads trying read the same socket, or write to the same socket would be a mess. So why do we expect it is ok to have one thread reading and a different thread writing? But, even if we do restrict ourselves to only accessing a socket from one thread at a time, we still have the issue that every place which uses threadWaitWrite needs to handle the disconnect case. We could, of course, write a wrapper function that does the check, and call that instead. But we still have not really solved the problem. The code in the I/O libraries that eventually implements hPut calls threadWaitWrite. But it has no idea that the file descriptor it is waiting on is a socket which has special requirements. That code is also used for writing to plain old files, etc, so it probably wouldn't make sense for it to behave that way by default.. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linear programming in Haskell
Alberto Ruiz wrote: I think that GSL does not include linear programming solvers, but in the GSL home page there is a reference to the GLPK package: http://www.gnu.org/software/glpk/glpk.html I have not used it, but it would be very nice to have a simple Haskell interface to GLPK (or other similar library) in hmatrix or as a separate package. I will take a look at this. I used GLPK many years ago and I found it excellent. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Threading and FFI
Yves Parès wrote: I've also discovered something interesting: when I link with the 'threaded' runtime, but let the program use only one core (with '+RTS -N1'), the problem disappears. How comes? The whole thing remains a mystery, because I think what I'm trying to do is quite common... Yves Parès wrote: There is a minimal code which produces this issue: http://old.nabble.com/file/p27613138/func.c func.c http://old.nabble.com/file/p27613138/main.hs main.hs Yves Parès wrote: Well I tried both 'unsafe' and 'safe', and actually I saw no difference... Even with 'safe', I see a huge difference between calling a C function which sleeps and another which doesn't. When there is a sleep, the other thread is really slower (it just prints numbers, and I look at which pace they're displayed). This is to be expected. From the docs (http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Concurrent.html#10): The downside of having lightweight threads is that only one can run at a time, so if one thread blocks in a foreign call, for example, the other threads cannot continue. The GHC runtime works around this by making use of full OS threads where necessary. When the program is built with the -threaded option (to link against the multithreaded version of the runtime), a thread making a safe foreign call will not block the other threads in the system; another OS thread will take over running Haskell threads until the original call returns. The runtime maintains a pool of these worker threads so that multiple Haskell threads can be involved in external calls simultaneously. IIRC, with -threaded, the RTS spawns a separate OS thread for 'safe' foreign calls _in addition_ to the OS threads used for Haskell code (the number of which you give with the +RTS -Nn option). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linear programming in Haskell
Interesting. Do you have any details on this? It seems like it would be hard to express system of linear inequalities as a finite system of linear equations. Thanks, Dan 2010/2/17 Matthias Görgens matthias.goerg...@googlemail.com As far as I can see, you'd use that for systems of linear equalities, but for systems of linear inequalities with a linear objective function, it's not suitable. I may be wrong though :) There's a linear [1] reduction from one problem to the other and vice versa. [1] The transformation itself is a linear function, and it takes O(n) time, too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree composition for higher arity
Hi Sean
Thanks for the comment.
David Menendez pointed out on the other thread that they generalize
nicely to functors:
http://www.haskell.org/pipermail/haskell-cafe/2009-December/071428.html
Typographically they are a pun on ML's composition operator (o), if
you don't define o - (aka 'monocle' - little need as we've already got
(.) ) then I'd imagine there won't be too many name clashes with
people's existing code. 'Specs' was an obvious name for the family
once you use them infix.
Many of the combinator 'birds' that aren't already used by Haskell
seem most useful for permuting other combinator birds rather than
programming with - their argument orders not being ideal. The most
useful ones I've found that expand to higher arities have the first
argument as a 'combiner' (combining all the intermediate results), one
or more 'functional' arguments (producing intermediate results from
the 'data' arguments), then the 'data' arguments themselves.
The liftM and liftA family are of this form, considering the
functional type instances ((-) a):
liftA :: (a - ans) - (r - a) - r - ans
liftA2 :: (a - b - ans) - (r - a) - (r - b) - r - ans
liftA3 :: (a - b - c - ans) - (r - a) - (r - b) - (r - c) - r - ans
... or the full general versions:
liftA :: Applicative f = (a - b) - f a - f b
liftA2 :: Applicative f = (a - b - c) - f a - f b - f c
liftA3 :: Applicative f = (a - b - c - d) - f a - f b - f c - f d
liftA for functions is bluebird
liftA2 for functions is phoenix or starling' or Big Phi
An arity family of Starlings can be quite nice for manipulating records.
starling :: (a - b - c) - (a - b) - a - c
star :: (a - r - ans) - (r - a) - r - ans
star2 :: (a - b - r - ans) - (r - a) - (r - b) - r - ans
star3 :: (a - b - c - r - ans) - (r - a) - (r - b) - (r - c)
- r - ans
star4 :: (a - b - c - d - r - ans)
- (r - a) - (r - b) - (r - c) - (r - d) - r - ans
star5 :: (a - b - c - d - e - r - ans)
- (r - a) - (r - b) - (r - c) - (r - d) - (r - e) - r - ans
An example - tracking the source position in a parser:
data SrcPos = SrcPos {
src_line :: Int,
src_column :: Int,
src_tab_stop :: Int
}
incrCol :: SrcPos - SrcPos
incrCol = star (\i s - s { src_column=i+1 }) src_column
incrTab :: SrcPos - SrcPos
incrTab = star2 (\i t s - s { src_column=i+t }) src_column src_tab_stop
incrLine :: SrcPos - SrcPos
incrLine = star (\i s - s { src_line =i+1, src_column=1 }) src_line
Permuted variants of cardinal-prime can be useful for adapting a
function to a slightly different type. I originally called them combfi
etc. 'f' to indicate where a function was applied, and 'i' where
identity was applied; but I'm no so happy with the name now:
combfi :: (c - b - d) - (a - c) - a - b - d
combfii :: (d - b - c - e) - (a - d) - a - b - c - e
combfiii :: (e - b - c - d - f) - (a - e) - a - b - c - d - f
I've sometimes used them to generalize a function's interface, e.g a
pretty printer:
f1 :: Doc - Doc - Doc
adapted_f1 :: Num a = a - Doc - Doc
adapted_f1 = f1 `combfi` (int . fromIntegral)
... not particularly compelling I'll admit.
Slowly I'm synthesizing sets of 'em when they seem to apply to an
interesting use. Actually finding valid uses and coining good
names is harder than defining them. The 'specs' were lucky in that
they pretty much named themselves.
Best wishes
Stephen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the meaning of tilde (~) symbol
On Sunday 14 February 2010 17:02:36 Henk-Jan van Tuyl wrote: The symbols that are not specified in a library can be found here: http://www.haskell.org/haskellwiki/Keywords Hoogle used to show links to this page, when a keyword was searched, but not anymore. This isn't Haskell 98 only, is it? :) *Adds type families, fundeps and the arcane arrow notation* -- Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threading and FFI
Okay! So under UNIX, haskell threaded runtime uses pthreads, if I well understood. To sum up, in order to achieve what I want, I have no other choice than compiling with '-threading' and importing as 'safe' the functions which can make a 'sleep'. Thanks! Ben Franksen wrote: Yves Parès wrote: I've also discovered something interesting: when I link with the 'threaded' runtime, but let the program use only one core (with '+RTS -N1'), the problem disappears. How comes? The whole thing remains a mystery, because I think what I'm trying to do is quite common... Yves Parès wrote: There is a minimal code which produces this issue: http://old.nabble.com/file/p27613138/func.c func.c http://old.nabble.com/file/p27613138/main.hs main.hs Yves Parès wrote: Well I tried both 'unsafe' and 'safe', and actually I saw no difference... Even with 'safe', I see a huge difference between calling a C function which sleeps and another which doesn't. When there is a sleep, the other thread is really slower (it just prints numbers, and I look at which pace they're displayed). This is to be expected. From the docs (http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Concurrent.html#10): The downside of having lightweight threads is that only one can run at a time, so if one thread blocks in a foreign call, for example, the other threads cannot continue. The GHC runtime works around this by making use of full OS threads where necessary. When the program is built with the -threaded option (to link against the multithreaded version of the runtime), a thread making a safe foreign call will not block the other threads in the system; another OS thread will take over running Haskell threads until the original call returns. The runtime maintains a pool of these worker threads so that multiple Haskell threads can be involved in external calls simultaneously. IIRC, with -threaded, the RTS spawns a separate OS thread for 'safe' foreign calls _in addition_ to the OS threads used for Haskell code (the number of which you give with the +RTS -Nn option). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27631980.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
On Wed, Feb 17, 2010 at 6:58 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Ah, I meant to use the union' from your previous message, but I think that doesn't work because it doesn't have the crucial property that the case union (VIP x xs) ys = ... does not pattern match on the second argument. Ahh yes, the funny thing is that I tested the code in my previous message, and it worked in the infinite case. Then I replaced the union' to pattern match on the second argument as well, and tested it on only finite cases, and then released it.Thus, unionAll in data-ordlist-0.4.1 doesn't work on an infinite number of lists. So my original unionAll in data-ordlist-0.4 appears to work ok, my revised and simplified unionAll doesn't work at all. The easiest solution is simply to define unionAll = nub . mergeAll where -- specialized definition of nub nub = map head . groupBy (==) Incidentally, data-ordlist has a (slightly different) version of nub that does exactly what you want in this particular case.Check out the documentation for nub and nubBy But you're probably concerned that filtering for duplicates afterwards will be less efficient. After all, the (implicit) tree built by mergeAll might needlessly compare a lot of equal elements. Well, yes and no. Efficiency is good, but this implementation does not match my intention.For example: unionAll [[1,1,2,2,2],[1,1,1,2]] == foldr union [] [...] == [1,1,1,2,2,2] The union function preserves strictly ascending lists, but it also works on multisets as well, returning an element as many times as the maximum number of times in either list.Thus, on an infinite number of lists, unionAll should return a particular element as many times as the maximum number of times it appears in any single list. On Wed, Feb 17, 2010 at 1:18 PM, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Mittwoch 17 Februar 2010 18:59:42 schrieb Ozgur Akgun: Ooops I thought the inner lists are possibly of infinite size. Both, I think. Yes, both the inner and outer lists of an input to unionAll might be infinite.It's just that foldr union [] works fine if the inner lists are infinite, but gets stuck in an infinite non-productive list if the outer list is infinite. Best, Leon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GUI (was: Re: [Haskell-cafe] DLL on Windows)
On Wed, Feb 17, 2010 at 3:17 AM, Jeremy O'Donoghue
jeremy.odonog...@gmail.com wrote:
You're probably correct about the dependencies. I have never tried to
compile wxHaskell against GHC 6.12.1
I'm waiting for Haskell Platform to be released to make the required
changes since (working primarily on Windows) I just don't have time to
create a complete GHC 6.12 installation with most of the HP libraries
(some of which are a pain to get working on Windows).
FYI, it also seems the current version of wxcore assumes something
that isn't true about Cabal (again, I use Cabal 1.8.0.2). I just
tested with ghc-6.10.4 + Cabal 1.8.0.2 + cabal-install 0.8.0 and
received what is probably a well known complaint:
[to...@mavlo ~]$ cabal install wx
Resolving dependencies...
[1 of 1] Compiling Main (
/tmp/wxcore-0.12.1.23133/wxcore-0.12.1.2/Setup.hs,
/tmp/wxcore-0.12.1.23133/wxcore-0.12.1.2/dist/setup/Main.o )
/tmp/wxcore-0.12.1.23133/wxcore-0.12.1.2/Setup.hs:15:57:
Couldn't match expected type `GenericPackageDescription'
against inferred type `Either
GenericPackageDescription
PackageDescription'
Expected type: (GenericPackageDescription, HookedBuildInfo)
Inferred type: (Either
GenericPackageDescription PackageDescription,
HookedBuildInfo)
In the `confHook' field of a record
In the first argument of `defaultMainWithHooks', namely
`simpleUserHooks {confHook = myConfHook}'
/tmp/wxcore-0.12.1.23133/wxcore-0.12.1.2/Setup.hs:51:37:
Couldn't match expected type `GenericPackageDescription'
against inferred type `Either
GenericPackageDescription
PackageDescription'
In the expression: pkg0
In the second argument of `confHook', namely `(pkg0, pbi)'
In a stmt of a 'do' expression:
lbi - confHook simpleUserHooks (pkg0, pbi) flags
cabal: Error: some packages failed to install:
wx-0.12.1.2 depends on wxcore-0.12.1.2 which failed to install.
wxcore-0.12.1.2 failed during the configure step. The exception was:
ExitFailure 1
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
I haven't seen anybody mentioning «Joy of Cats» by Adámek, Herrlich Strecker: It is available online, and is very well-equipped with thorough explanations, examples, exercises funny illustrations, I would say best of university lecture style: http://katmat.math.uni-bremen.de/acc/. (Actually, the name of the book is a joke on the set theorists' book «Joy of Set», which again is a joke on «Joy of Sex», which I once found in my parents' bookshelf... ;-)) Another alternative: Personally, I had difficulties with the somewhat arbitrary terminology, at times a hindrance to intuitive understanding - and found intuitive access by programming examples, and the book was «Computational Category Theory» by Rydeheart Burstall, also now available online at http://www.cs.man.ac.uk/~david/categories/book/, done with the functional language ML. Later I translated parts of it to Haskell which was great fun, and the books content is more beginner level than any other book I've seen yet. The is also a programming language project dedicated to category theory, «Charity», at the university of Calgary: http://pll.cpsc.ucalgary.ca/charity1/www/home.html. Any volunteers in doing a RENAME REFACTORING of category theory together with me?? ;-)) Cheers, Nick Mark Spezzano wrote: Hi all, I'm trying to learn Haskell and have come across Monads. I kind of understand monads now, but I would really like to understand where they come from. So I got a copy of Barr and Well's Category Theory for Computing Science Third Edition, but the book has really left me dumbfounded. It's a good book. But I'm just having trouble with the proofs in Chapter 1--let alone reading the rest of the text. Are there any references to things like Hom Sets and Hom Functions in the literature somewhere and how to use them? The only book I know that uses them is this one. Has anyone else found it frustratingly difficult to find details on easy-to-diget material on Category theory. The Chapter that I'm stuck on is actually labelled Preliminaries and so I reason that if I can't do this, then there's not much hope for me understanding the rest of the book... Maybe there are books on Discrete maths or Algebra or Set Theory that deal more with Hom Sets and Hom Functions? Thanks, Mark Spezzano. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: sendfile leaking descriptors on Linux?
On Wed, Feb 17, 2010 at 3:54 PM, Jeremy Shaw jer...@n-heptane.com wrote: On Wed, Feb 17, 2010 at 1:27 PM, Bardur Arantsson s...@scientician.netwrote: (Obviously, if people are using sendfile with something other than happstack, it does not help them, but it sounds like trying to fix things in sendfile is misguided anyway.) How so? As a user I expect sendfile to work and not semi-randomly block threads indefinitely. Because it only addresses *one* case when this type of blocking can happen. Shouldn't hPut and friends also block indefinitely since they also use threadWaitWrite? If so, what good is just fixing sendfile, when all other network I/O will still block indefinitely? If things are 'fixed' at a higher-level, by using SO_KEEPALIVE, then does sendfile really need a hack to deal with it? I think I understand the SO_KEEPALIVE + SO_ERROR solution, and that does not really fix things either. Setting SO_KEEPALIVE by itself does not cause the write select() to behave any differently. What it does do is cause the TCP stack to eventually send and empty packet to the remote host and hopefully get a response back. The response might be an error, or it might just be an ACK. But either way, I believe it is intended to cause the read select() to wakeup. But, in the case that started this discussion, we are already getting this information. So this won't help with that at all. The second part of the solution is to poll SO_ERROR to determine if something went wrong. This is an alternative to doing a read() on the socket and see if it returns 0 bytes. It is a nice alternative *because* it does not require a read(). However, it is still problematic. When you poll SO_ERROR, it will clear the error value, so there is a potential race condition if multiple threads are doing it. In happstack, we fork a new thread to handle each incoming connection. So at first it seems like we could just fork a second thread that polls the SO_ERROR option on the socket and kills the first thread if an error happens. Unfortunately, it is not that simple. The first thread might fork another thread that is actually doing the threadWaitWrite. Killing the parent thread will not kill that child thread. So, at present, I don't see a solution that is going to fix the problem in the rest of the IO code. There are multiple ways to hack only sendfile.. but that is only one place this error can happen. If this error truly never happens with hPut, then we should figure out why. If there is a solution that works for write() it should work for sendfile(), because the real issue is with the select() call anyway.. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
On Wed, Feb 17, 2010 at 6:58 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Ah, I meant to use the union' from your previous message, but I think that doesn't work because it doesn't have the crucial property that the case union (VIP x xs) ys = ... does not pattern match on the second argument. Ahh yes, my original union' has a bit that looks like this union' (VIP x xs) (VIP y ys) = case cmp x y of LT - VIP x (union' xs (VIP y ys)) EQ - VIP x (union' xs ys) GT - error Data.List.Ordered.unionAll: assumption violated! union' (VIP x xs) (Crowd ys) = VIP x (union' xs (Crowd ys)) For whatever reason, this works in the case of an infinite number of lists with my original version, but not the simplified version. By applying a standard transformation to make this lazier, we can rewrite these clauses as union' (VIP x xs) ys = VIP x $ case ys of Crowd _ - union' xs ys VIP y yt - case cmp x y of LT - union' xs ys EQ - union' xs yt GT - error msg In the original case, we have this strictness property union' (VIP x xs) ⊥ == ⊥ The revised verison is a bit lazier: union' (VIP x xs) ⊥ == VIP x ⊥ And so the simplified unionAll now works again on an infinite number of lists. I've uploaded data-ordlist-0.4.2 to fix the bug introduced with data-ordlist-0.4.1, and added a regression test to the suite. Best, Leon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Threading and FFI
Hello Yves, Thursday, February 18, 2010, 2:10:42 AM, you wrote: Okay! So under UNIX, haskell threaded runtime uses pthreads, if I well understood. not exactly. it still uses lightweight (green) threads, but starts additional OS threads as required to keep N haskell threads running. it's very smart To sum up, in order to achieve what I want, I have no other choice than compiling with '-threading' and importing as 'safe' the functions which can make a 'sleep'. Thanks! Ben Franksen wrote: Yves Pares wrote: I've also discovered something interesting: when I link with the 'threaded' runtime, but let the program use only one core (with '+RTS -N1'), the problem disappears. How comes? The whole thing remains a mystery, because I think what I'm trying to do is quite common... Yves Pares wrote: There is a minimal code which produces this issue: http://old.nabble.com/file/p27613138/func.c func.c http://old.nabble.com/file/p27613138/main.hs main.hs Yves Pares wrote: Well I tried both 'unsafe' and 'safe', and actually I saw no difference... Even with 'safe', I see a huge difference between calling a C function which sleeps and another which doesn't. When there is a sleep, the other thread is really slower (it just prints numbers, and I look at which pace they're displayed). This is to be expected. From the docs (http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Concurrent.html#10): The downside of having lightweight threads is that only one can run at a time, so if one thread blocks in a foreign call, for example, the other threads cannot continue. The GHC runtime works around this by making use of full OS threads where necessary. When the program is built with the -threaded option (to link against the multithreaded version of the runtime), a thread making a safe foreign call will not block the other threads in the system; another OS thread will take over running Haskell threads until the original call returns. The runtime maintains a pool of these worker threads so that multiple Haskell threads can be involved in external calls simultaneously. IIRC, with -threaded, the RTS spawns a separate OS thread for 'safe' foreign calls _in addition_ to the OS threads used for Haskell code (the number of which you give with the +RTS -Nn option). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - Yves Pares Live long and prosper -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Pointfree composition for higher arity
Sean Leather wrote: (...) :: (c - d) - (a - b - c) - a - b - d (...) f g x y = f (g x y) Does anybody else care about this? What are some alternative solutions? Here is a different solution: http://okmij.org/ftp/Haskell/polyvariadic.html#polyvar-comp f:: a1-a2- -cp (where cp is not a function type) g:: cp-d f `mcomp` g:: a1-a2- -d Now that we know how to generically decide if a type is not a functional type, mcomp can be defined fully generically, for any type cp that is not a function. If there is interest, I can write that code. One particular application of the mcomp combinator is the prod combinator: Given two functions, f:: a1-a2-...-an-c |c,d non-exponential types g:: b1-b2-...-bn-d their product f `prod` g:: a1-a2-...-an-b1-b2-...-bn-(c,d) The number of as and bs is arbitrary. The definition of prod is very simple: prod = (. ((. (,)) . mcomp)) . mcomp The web page http://okmij.org/ftp/Haskell/polyvariadic.html#categorical-max3 gives a few explanations and further examples. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
By purest coincidence I just wrote the exact same function (the simple mergeAll', not the VIP one). Well, extensionally the same... intensionally mine is 32 complicated lines and equivalent to the 3 line mergeAll'. I even thought of short solution by thinking that pulling the first element destroys the ascending lists property so it's equivalent to a normal sorted merge after that, and have no idea why I didn't just write it that way. Anyway, I'm dropping mine and downloading data-ordlist. Thanks for the library *and* the learning experience :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] [2]: Threading and FFI
Thank you all. But there are two things that remain obscure: First, there is my situation: int the main thread, I call to some C functions binded through FFI. All of them are marked 'unsafe', except one, which is internally supposed to make pauses with 'usleep'. I then execute in another haskell thread (with forkIO) some pure haskell actions. I then compile with the threaded RTS, and let at run the default behaviour which is to use one core. Question 1) What happens to the unsafe C functions? I that simply that the threaded RTS is unable to prevent them from blocking haskell threads (which in my case is a problem only for the function which pauses, since other C calls are fast)? Or they could provoke a hazardous issue, so I have to mark all the C functions as safe (which will be much slower) because ? Question 2) In the Control.Concurrent documentation, I understood that forkIO creates unbound threads whereas forkOS creates bound threads, but what is not very clear is: when does GHC threaded runtime launches as bound instead of unbound if this one has been started with forkIO? When it detects the thread calls to a C function? When it detects it calls to a safe C function (*)? When it detects another thread calls to a (safe) C function (which is my case)? (*) according to documentation it would be this case. However as I said my C calls are done in the MAIN thread. The other thread just executes casual haskell operations, however it is not blocked, which makes me think that even if I launch it with forkIO, it is launched as an bound thread. Bulat Ziganshin-2 wrote: Hello Yves, Thursday, February 18, 2010, 2:10:42 AM, you wrote: Okay! So under UNIX, haskell threaded runtime uses pthreads, if I well understood. not exactly. it still uses lightweight (green) threads, but starts additional OS threads as required to keep N haskell threads running. it's very smart To sum up, in order to achieve what I want, I have no other choice than compiling with '-threading' and importing as 'safe' the functions which can make a 'sleep'. Thanks! - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27635260.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
