Re: [Haskell-cafe] Status update on {code, trac, projects, planet, community}.haskell.org
I believe code.haskell.org has moved to a new machine. Its IP address also changed, which causes your ssh to issue a warning. You can fix it by deleting the code.haskell.org entry from your local ~/.ssh/known_hosts file. On 16 February 2011 18:58, Henning Thielemann lemm...@henning-thielemann.de wrote: Thank you a lot for bringing code.haskell.org back! I missed it a lot! However, I still get $ ssh code.haskell.org @@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@ The RSA host key for code.haskell.org has changed, and the key for the according IP address 178.63.91.44 is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. @@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. ... How can I verify that it is safe to continue logging in? Could you restore the old host key? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] upgrading mtl1 to mtl2
On Thu, Feb 17, 2011 at 4:57 PM, Max Bolingbroke batterseapo...@hotmail.com wrote: I think the problem is that the mtl1 Functor instances looked like: instance Monad m = Functor (ReaderT e m) where fmap = ... But the mtl2/transformers instances look like: instance Functor f = Functor (ReaderT e f) where fmap = ... I see! So the problem is not that previously (Monad m) implied (Functor m) (which has been proposed only recently) but that previously many Functor instances required (Monad m) but now require (Functor m). Thanks for the clarification, Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On 16/02/2011 08:39, Bas van Dijk wrote: timeout :: Int - IO a - IO (Maybe a) timeout n f | n 0= fmap Just f | n == 0= return Nothing | otherwise = do myTid- myThreadId timeoutEx- fmap Timeout newUnique uninterruptibleMask $ \restore - do tid- restore $ forkIO $ threadDelay n throwTo myTid timeoutEx let handle e = case fromException (e :: SomeException) of Just timeoutEx' | timeoutEx' == timeoutEx - return Nothing _ - killThread tid throwIO e mb- restore (fmap Just f) `catch` handle killThread tid return mb If nobody proves it incorrect I will make a patch for the base library. uninterruptibleMask is quite unsavoury, I don't think we should use it here. I can see why you used it though: the killThread in the main thread will always win over the throwTo in the timeout thread, and that lets you avoid the outer exception handler. Hmm, it makes me uncomfortable, but I can't find any actual bugs. At the very least it needs some careful commentary to explain how it works. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On 16/02/2011 23:27, Bas van Dijk wrote:
On 16 February 2011 20:26, Bas van Dijkv.dijk@gmail.com wrote:
The patch and benchmarks attached to the ticket are updated. Hopefully
this is the last change I had to make so I can stop spamming.
And the spamming continues...
I started working on a hopefully even more efficient timeout that uses
the new GHC event manager.
The idea is that instead of forking a thread which delays for the
timeout period after which it throws a Timeout exception, I register a
timeout with the event manager. When the timeout fires the event
manager will throw the Timeout exception.
I haven't gotten around testing and benchmarking this yet. I hope to
do that tomorrow evening.
The code is currently living in the System.Event.Thread module:
module System.Event.Thread where
...
import Data.Typeable
import Text.Show (Show, show)
import GHC.Conc.Sync (myThreadId, throwTo)
import GHC.IO (throwIO,unsafePerformIO )
import GHC.Exception (Exception, fromException)
import Control.Exception.Base (catch)
-- I'm currently using the Unique from System.Event
-- because I got a circular import error when using Data.Unique:
import System.Event.Unique (UniqueSource, newSource, Unique, newUnique)
uniqSource :: UniqueSource
uniqSource = unsafePerformIO newSource
{-# NOINLINE uniqSource #-}
newtype Timeout = Timeout Unique deriving Eq
INSTANCE_TYPEABLE0(Timeout,timeoutTc,Timeout)
instance Show Timeout where
show _ = timeout
instance Exception Timeout
timeout :: Int - IO a - IO (Maybe a)
timeout usecs f
| usecs 0 = fmap Just f
| usecs == 0 = return Nothing
| otherwise = do
myTid- myThreadId
uniq- newUnique uniqSource
let timeoutEx = Timeout uniq
Just mgr- readIORef eventManager
mask $ \restore - do
reg- registerTimeout mgr usecs (throwTo myTid timeoutEx)
let unregTimeout = M.unregisterTimeout mgr reg
(restore (fmap Just f)= \mb - unregTimeout return mb)
`catch` \e -
case fromException e of
Just timeoutEx' | timeoutEx' == timeoutEx - return Nothing
_ - unregTimeout throwIO e
If this version works, it's definitely preferable to your first
proposal. It relies on unregisterTimeout not being interruptible -
otherwise you're back to uninterruptibleMask again.
Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using MonadFix to tie the knot with STM
On 16/02/2011 12:46, Sebastiaan Visser wrote:
On Feb 12, 2011, at 6:08 PM, Antoine Latter wrote:
On Sat, Feb 12, 2011 at 8:47 AM, Sebastiaan Visserhask...@fvisser.nl wrote:
Hi all,
During a little experiment I discovered there is no MonadFix instance available
for the STM monad. Is this absence the consequence of some deep restriction of
how STM works or 'just accidental'? Is there some way I could derive this
instance?
If you port `fixST` to the STM monad, it seems to work fine at first glance:
http://hpaste.org/43915/fixstm
But I would want someone else's opinion on it to make sure I'm not
doing something like introducing lazy STM values that violate
atomicity, or something. The strict `case` on the return value makes
me feel pretty good about it.
Antoine
Interesting! This approach seems to work for my examples as well. Unfortunately
I do not have enough insides into STM to be able to tell if the code is correct.
Does someone else have an opinion on this? When not I might propose adding the
instance to the STM package.
I think it's ok. Go ahead and propose it.
Cheers,
Simon
Sebastiaan
For those who are interested and may know other ways to solve my problem, I'm
trying to tie the knot in a graph by using transactional variables as the edges
between nodes. I'm trying to do this in a rather generic way:
{-# LANGUAGE DeriveFunctor, DeriveFoldable, DeriveTraversable,
StandaloneDeriving, DoRec #-}
module Graph where
import Control.Applicative
import Control.Concurrent.STM
import Control.Monad.Fix
import Data.Maybe
import Data.Foldable
import Data.Traversable
import Prelude hiding (mapM)
import qualified Data.Map as M
instance MonadFix STM where
mfix = error I need this instance! -- What to do?
-- A single node is a graph, has a list of both incoming and outgoing edges.
data Node edge = Node
{ nodeId :: NodeId
, payload :: String
, incoming :: [edge]
, ougoing :: [edge]
} deriving (Functor, Foldable, Traversable)
type NodeId = String
-- A graph with an index on the nodes by NodeId, parametrized with the type we
-- want to used as the edge pointer.
type Graph edge = M.Map NodeId (Node edge)
-- Type level fixed point combinator with a TVar annotation.
newtype TFix f = TIn { tout :: TVar (f (TFix f)) }
-- Take a graph that uses NodeIds as edges and recursively transform it into a
-- graph with TVars to the neighbouring nodes in the edges.
tieTheKnot :: Graph NodeId - STM (Graph (TFix Node))
tieTheKnot untied =
do rec tied- (mapM . mapM) (\nodeid - TIn$ newTVar (tryLookup nodeid
tied)) untied
return tied
-- Helper function to lookup a pre-tied node from a graph, throws an error when
-- the edge could not be resolved. This should, of course, not happen!
tryLookup :: NodeId - Graph (TFix Node) - Node (TFix Node)
tryLookup i = fromJust (error msg) . M.lookup i
where msg = tieTheKnot: Lookup error, input is an incomplete graph.
Thanks in advance,
--
Sebastiaan Visser
http://www.silkapp.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] happy + alex parsing question
Thanks,
adding state to lexer seems to be the way to go.
2011/2/16 Mihai Maruseac mihai.marus...@gmail.com
On Wed, Feb 16, 2011 at 5:31 PM, Roman Dzvinkovsky romand...@gmail.com
wrote:
Hi,
using alex+happy, how could I parse lines like these?
mr username says message\n
where both username and message may contain arbitrary characters
(except
eol)?
If I make lexer tokens
mr { T_Mr }
says { T_Says }
\r?\n{ T_Eol }
.{ T_Char $$ }
and parser
'mr '{ T_Mr }
' says ' { T_Says }
eol { T_Eol }
char { T_Char }
...
line :: { (String, String) }
: 'mr ' string ' says ' string eol { ($2, $4) }
string :: { String }
: char{ [ $1 ] }
| char string { $1 : $2 }
then I get error when username or message contain mr
substrings, because parser encounters T_Mr token.
Workaround is mention all small tokens in my string definition:
string :: { String }
: { [] }
| 'mr ' string{ mr ++ $2 }
| ' says ' string { says ++ $2 }
| char string { $1 : $2 }
but that is weird and I'm sure there is a better way.
I don't have an implementation right now but you could try having some
states or user data in which to record whether you have already parsed
the 'mr ' part (etc..) Guess you could use monadUserData parser (just
like I've found after a night without sleep [1] - solved now).
--
Mihai
[1]:
http://www.haskell.org/pipermail/haskell-cafe/2011-February/089330.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alex monadUserState question
On Thu, Feb 17, 2011 at 2:42 PM, Simon Marlow simon...@microsoft.com wrote:
Just downloaded the latest Alex package from Hackage (different from
the one in Ubuntu's repositories by 2 minor versions) and found that
the monadUserState wrapper still misses 2 functions for dealing with
changes in the user supplied state. Is this intended or it was an
unwanted omission?
Could you tell me what's missing? Is this a regression?
Yes, there are two functions (this is the type that I guess they should have)
getUserData :: Alex AlexUserState
setUserData :: AlexUserState - Alex ()
I've used them in a particular implementation today in this way but
maybe there are other ways to handle them too.
He're the code I've used:
getUserData :: Alex AlexUserState
getUserData = Alex $ \s@AlexState{alex_ust=ud} - Right (s, ud)
setUserData :: AlexUserState - Alex ()
setUserData ust = Alex $ \s - Right (s{alex_ust=ust}, ())
Thanks for the quick input,
--
Mihai
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unable to get parallelism using `par`
Hi, I tried the first example from A tutorial on Parallel and Concurrent programming in Haskell but I cant seem to get sparks to get converted to OS threads. Below is the program I am using. I did ghc --make -threaded program.hs then ./program +RTS -N2 I don't see any speed gain compared to N1. Am I missing something? import System.Time import Control.Parallel fib :: Int - Int fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) mkList :: Int - [Int] mkList n = [1..n-1] relPrime :: Int - Int - Bool relPrime x y = gcd x y == 1 euler :: Int - Int euler n = length (filter (relPrime n) (mkList n)) sumEuler :: Int - Int sumEuler = sum . (map euler) . mkList sumFibEuler :: Int - Int - Int sumFibEuler a b = fib a + sumEuler b parSumFibEuler :: Int - Int - Int parSumFibEuler a b = f `par` (e `pseq` (e + f)) where f = fib a e = sumEuler b secDiff :: ClockTime - ClockTime - Float secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) = fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - secs1) r1 :: Int r1 = sumFibEuler 38 5300 main :: IO () main = do t0 - getClockTime pseq r1 (return()) t1 - getClockTime putStrLn (Sum: ++ show r1) putStrLn (time: ++ show (secDiff t0 t1) ++ seconds) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unable to get parallelism using `par`
On Thursday 17 February 2011 17:02:55, C K Kashyap wrote: Hi, I tried the first example from A tutorial on Parallel and Concurrent programming in Haskell but I cant seem to get sparks to get converted to OS threads. Below is the program I am using. I did ghc --make -threaded program.hs then ./program +RTS -N2 I don't see any speed gain compared to N1. Am I missing something? Hmm, using parSumFibEuler instead of sumFibEuler, I get 100% CPU usage (close to 200% if I adjust parameters so both computations take approximately the same time). Works for me, then. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unable to get parallelism using `par`
From: C K Kashyap ckkash...@gmail.com Hi, I tried the first example from A tutorial on Parallel and Concurrent programming in Haskell but I cant seem to get sparks to get converted to OS threads. Below is the program I am using. I did ghc --make -threaded program.hs then ./program +RTS -N2 I don't see any speed gain compared to N1. Am I missing something? If you are using ghc 7.01, you need to compile with -rtsopts for the compiled program to parse +RTS options. I don't know of any way to provide a default value at compile time. http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/runtime-control.html Also, in general a program might not run faster with speculation, so if you want to check if several threads are used, check if CPU time used is over 100%. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status update on {code, trac, projects, planet, community}.haskell.org
Duncan Coutts schrieb: Several people have asked about the new host key. Yes, there is a new RSA host key for the community server, the fingerprint of which is: 21:b8:59:ff:39:69:58:7a:51:ef:c1:d8:c6:24:6e:f7 ssh will likely give you a scary warning and you'll need to delete the old entry in your ~/.ssh/known_hosts file. You don't need to enter a new one, just delete the old one. When you next log into the server, ssh will ask you if you're happy with the new key. If you're paranoid, you can double check that it matches the key fingerprint above. Do you think it is paranoid? Unfortunately it has become quite common to ignore SSH warnings because admins often do not care about restoring keys when updating the operating system or moving the machine, even not telling users that the host key has changed. But if I had ignored the SSH warning on code.haskell.org recently I might have logged in and from there maybe to other servers, thus giving my passwords to the attackers. I think generally that just deleting a host from known_hosts in response to an SSH warning and blindly accepting a new host key is not a fix. Am I too afraid? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status update on {code, trac, projects, planet, community}.haskell.org
On Thu, Feb 17, 2011 at 07:30:23PM +0100, Henning Thielemann wrote: Do you think it is paranoid? Unfortunately it has become quite common to ignore SSH warnings because admins often do not care about restoring keys when updating the operating system or moving the machine, even not telling users that the host key has changed. But if I had ignored the SSH warning on code.haskell.org recently I might have logged in and from there maybe to other servers, thus giving my passwords to the attackers. I think generally that just deleting a host from known_hosts in response to an SSH warning and blindly accepting a new host key is not a fix. Am I too afraid? If sshd has been compromised, so is the original host private key. It would be kind of pointless (security wise) to restore it on the new server. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status update on {code, trac, projects, planet, community}.haskell.org
2011/2/17 Henning Thielemann lemm...@henning-thielemann.de: Duncan Coutts schrieb: Several people have asked about the new host key. Yes, there is a new RSA host key for the community server, the fingerprint of which is: 21:b8:59:ff:39:69:58:7a:51:ef:c1:d8:c6:24:6e:f7 ssh will likely give you a scary warning and you'll need to delete the old entry in your ~/.ssh/known_hosts file. You don't need to enter a new one, just delete the old one. When you next log into the server, ssh will ask you if you're happy with the new key. If you're paranoid, you can double check that it matches the key fingerprint above. Do you think it is paranoid? Unfortunately it has become quite common to ignore SSH warnings because admins often do not care about restoring keys when updating the operating system or moving the machine, even not telling users that the host key has changed. But if I had ignored the SSH warning on code.haskell.org recently I might have logged in and from there maybe to other servers, thus giving my passwords to the attackers. I think generally that just deleting a host from known_hosts in response to an SSH warning and blindly accepting a new host key is not a fix. Am I too afraid? Hi, Regarding you giving passwords when logging in other marchines, I think it would not be the case if you only use key authentication from machines to machines. Your private key can be only on your local machine and you can use an ssh agent to do log from machines to machines. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On 17 February 2011 13:09, Simon Marlow marlo...@gmail.com wrote:
uninterruptibleMask is quite unsavoury,
Agreed, that's why I called this implementation fragile because it
relies on the, not well known semantics, of interruptible operations.
I don't think we should use it here.
I agree that it looks fishy. However the biggest part of the
computation passed to uninterruptibleMask is running in the restored
state. The only part that is running in uninterruptible masked state
that may potentially block (and thus potentially deadlock) is the
killThread in the exception handler. However since the timeout thread
is running inside unsafeUnmask it is ensured that the ThreadKilled
exception always gets thrown.
I can see why you used it though: the killThread in the main thread will
always win over the throwTo in the timeout thread, and that lets you avoid
the outer exception handler.
Yes, and I think that the removal of the outer exception handler makes
the code run so much faster.
Hmm, it makes me uncomfortable, but I can't find any actual bugs. At the
very least it needs some careful commentary to explain how it works.
Good point, I will add a comment with an explanation how it works.
My brother Roel had an interesting idea how to make the code run even
faster by replacing the Unique with the ThreadId of the timeout
thread. I implemented it and it now runs 19 times faster than the
original compared to the 13 times faster of my previous version.
Here's the new implementation:
newtype Timeout = Timeout ThreadId deriving (Eq, Typeable)
instance Show Timeout where
show _ = timeout
instance Exception Timeout
timeout :: Int - IO a - IO (Maybe a)
timeout n f
| n 0= fmap Just f
| n == 0= return Nothing
| otherwise = do
myTid - myThreadId
uninterruptibleMask $ \restore - do
tid - unsafeUnmask $ forkIO $ do
tid - myThreadId
threadDelay n
throwTo myTid $ Timeout tid
(restore (fmap Just f) = \mb - killThread tid return mb)
`catch` \e -
case fromException e of
Just (Timeout tid') | tid' == tid - return Nothing
_ - killThread tid throwIO e
It relies on ThreadIds being unique, but I believe this is the case
because otherwise the throwTo operation will be nondeterministic,
right?
Obviously, this trick won't work in the event-manager-based version
because I don't fork a thread there. So I have to keep using Uniques
in that version. Speaking of Uniques: what is the best way to create
them? I see 3 options:
* Data.Unique. I tried using it but got a circular import error. Maybe
I can get around that with a boot file.
* System.Event.Unique. This is what I currently use. However I need to
create a UniqSource for the newUnique function which may be a bit
ugly:
uniqSource :: UniqueSource
uniqSource = unsafePerformIO newSource
{-# NOINLINE uniqSource #-}
* Also use System.Event.Unique but get the UniqSource from the
EventManager. This does require that the emUniqueSource function is
exported which it currently isnt't.
Johan what do you think?
import System.Event.Manager (emUniqueSource)
timeout :: Int - IO a - IO (Maybe a)
timeout usecs f
| usecs 0 = fmap Just f
| usecs == 0 = return Nothing
| otherwise = do
myTid - myThreadId
Just mgr - readIORef eventManager
uniq - newUnique $ emUniqueSource mgr
let timeoutEx = Timeout uniq
mask $ \restore - do
reg - registerTimeout mgr usecs (throwTo myTid timeoutEx)
let unregTimeout = M.unregisterTimeout mgr reg
(restore (fmap Just f) = \mb - unregTimeout return mb)
`catch` \e -
case fromException e of
Just timeoutEx' | timeoutEx' == timeoutEx - return Nothing
_ - unregTimeout throwIO e
Regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On 17 February 2011 20:34, Bas van Dijk v.dijk@gmail.com wrote: Speaking of Uniques: what is the best way to create them? I see 3 options: There may be a 4th option but it requires changing the System.Event.Manager.registerTimeout function from: registerTimeout :: EventManager - Int - TimeoutCallback - IO TimeoutKey to: registerTimeout :: EventManager - Int - (TimeoutKey - TimeoutCallback) - IO TimeoutKey Then we can use the TimeoutKey as our Unique (Note that a TimeoutKey is actually a newtype for a Unique): newtype Timeout = Timeout TimeoutKey deriving Eq instance Exception Timeout timeout :: Int - IO a - IO (Maybe a) timeout usecs f | usecs 0 = fmap Just f | usecs == 0 = return Nothing | otherwise = do myTid - myThreadId Just mgr - readIORef eventManager mask $ \restore - do reg - registerTimeout mgr usecs $ \reg - throwTo myTid $ Timeout reg let unregTimeout = M.unregisterTimeout mgr reg (restore (fmap Just f) = \mb - unregTimeout return mb) `catch` \e - case fromException e of Just (Timeout reg') | reg' == reg - return Nothing _ - unregTimeout throwIO e Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On Thu, Feb 17, 2011 at 11:53 AM, Bas van Dijk v.dijk@gmail.com wrote: Then we can use the TimeoutKey as our Unique (Note that a TimeoutKey is actually a newtype for a Unique): That should be fine. It's not a public API, so changing it like that shouldn't be an issue. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help needed for converting IOArray to ByteString
On Tue, 8 Feb 2011, C K Kashyap wrote: I need to convert IOArray to bytestring as shown below - import Data.Array.IO import Data.Binary.Put import qualified Data.ByteString.Lazy as BS import Data.Word main = do arr - newArray (0,9) 0 :: IO (IOArray Int Int) let bs=toByteString arr return () How can I implement the 'toByteString' function? Why do you want to convert? If you process images you might consider one of the Vector libraries like storable-vector or vector. You can work on them in a mutable way, write them to disk, pass them to C libraries and so on. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Web Framework Happstack 6 Released
Hello, I am pleased to announce the release of Happstack 6. We fully recommend that all Happstack users migrate to the new release. Happstack is a high-performance Haskell web framework. It has high- level functionality for routing requests, extracting parameters, manipulating responses, serving static file contents, compression responses, and more. It includes an integrated HTTP server and a native RAM-cloud database system known as MACID. This allows you to deploy your web application with out having to configure apache, php, mysql, memcached, etc! Install instructions can be found here: http://happstack.com/download If you are porting existing applications you should check out the Happstack 6 migration guide: http://code.google.com/p/happstack/wiki/Happstack6Migration Porting should be pretty straight-forward. Despite the massive reorganization, the exports from Happstack.Server are largely the same. What's Exciting! The focus of this release has been happstack-server. The primary goal was to make happstack-server much easier to learn and to use. This includes: 1. improving the overall organization of the library 2. greatly improving the documentation 3. making it easier to install 4. ensuring that the server provides fast, reliable performance 5. making it easier for new (and old) developers to understand and get started If you have looked at Happstack before and found it too difficult to understand, I highly recommend you take another look. The new organization and documentation make it far easier to understand. More Logical Organiation In prior versions, the Happstack.Server.SimpleHTTP module contained just about everything, with little organization, and no real differentiation between the external API and the library internals. In Happstack 6, SimpleHTTP has been refactored into numerous, smaller modules. The internals have been moved into Happstack.Server.Internal.* so that they are not leaking into the external API. This should make it much easier to find what you are looking for, and prevent you from accidently running across internal things like the WebT monad, which you do not really need to know anything about. Better Documentation The API documentation for happstack-server is also much better. All external API functions should now have good haddock documentation with many inline examples. However, learning a new library by studying the API documentation can still be pretty frustrating. So we also have the brand new Happstack Crash Course. http://happstack.com/docs/crashcourse/index.html. The Happstack Crash Course covers a vast majority of the happstack- server API. It covers the API in a logical manner and includes many downloadable, runnable examples. It is intended to be read start to finish, and to also be usable as a reference guide for specific How do I do XXX questions. Additionally, the guestbook example has been updated to a cleaner, more modern style of Happstack coding. It also has more comments/ haddock documentation. Better API -- During the process of documenting Happstack, many small improvements where made to the API. Once you try to document something stupid you realize how stupid it is and decided it would be good to fix it first ;) For example, the Cookie API now makes it more obvious how to create session cookies vs persistent cookies. And makes it obvious how to expire a cookie. The functions for looking up values in the query string and require body no longer require the use of the RqData monad. You can use the look* functions directly in the ServerPart monad. If you do choose to use RqData, it now has an Applicative instance which can accummulate and report lookup errors. (http://happstack.blogspot.com/2010/10/is-rqdata-monad-still-needed.html ) There are a bunch of other improvements to request data handling documented here, http://happstack.com/docs/crashcourse/RqData.html. Easier Install -- In order to make Happstack easier to install we have removed as many dependencies as possible. happstack-data no longer depends on happstack-util, which makes it easier to install happstack-data or happstack-state with out the rest of the framework. HSP and HStringTemplate support has been moved into *optional* happstack-hsp and happstack-hstringtemplate packages. New Features Happstack also has a number of new features including: - support for Heist templates(http://happstack.com/docs/crashcourse/Templates.html#helloheist ) - support for Hamlet templates - improved environment for extracting query string and form values (http://happstack.blogspot.com/2010/10/is-rqdata-monad-still-needed.html ) - support for recompilation and reloading of templates in a running server
Re: [Haskell-cafe] upgrading mtl1 to mtl2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/16/11 00:51 , Evan Laforge wrote: On Tue, Feb 15, 2011 at 7:58 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 February 2011 14:46, Evan Laforge qdun...@gmail.com wrote: I just got started on this because packages are starting to use mtl2. I had hoped it would be simple, and hopefully it is, but... Do I really have to add (Functor m) to the 300 or so functions with (Monad m) on them? Or just not use fmap or applicative? Use liftM instead of fmap if all of your functions are polymorphic in the type of Monad and you don't want to bother putting in the Functor constraint. There are hundreds of 'fmap's in there too. And even more $s and a scattering of *s. And... these functions are convenient! I like using them. If upgrading to mtl2 means porting away from Functor and Applicative... then that's even less of a minor incompatibility! At least the class context mangling can be mostly done with search and replace. Says that the only benefit of 'transformers' is that it's haskell 98 and thus more portable, but doesn't that come with the caveat that only if you don't use classes and do all the lifting manually? Yes, but some people don't want the extensions. Ok, so does that mean the migration to transformers so mtl could be deleted is cancelled? Or was rendered obsolete by mtl-2? Or maybe I was imagining it? I think minimal extensions is a worthy goal, but you can hardly position Y as the next step for X when all it is is X minus features that people still like... Yes; as I understand it, mtl2 is transformers + monad-fd, and the standard upgrade path is to go to mtl2. monads-tf is expected to eventually replace monads-fd, but it's not a near future change (for one thing, type families are still being figured out; see the recent thread about injective type functions as an example). It was decided that the mtl2 route would be easier than forcing people to replace mtl with transofrmers + monads-fd. - -- brandon s. allbery [linux,solaris,freebsd,perl]allber...@gmail.com system administrator [openafs,heimdal,too many hats]kf8nh -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1dtWMACgkQIn7hlCsL25WPFwCaA8MbZYbZr/gQ9pa/ttj/E5a0 pTgAoIZ9LMNuq4o7arXmTUZa5qTUFjx4 =NLta -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On Thu, Feb 17, 2011 at 2:43 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Thu, Feb 17, 2011 at 11:53 AM, Bas van Dijk v.dijk@gmail.com wrote: Then we can use the TimeoutKey as our Unique (Note that a TimeoutKey is actually a newtype for a Unique): That should be fine. It's not a public API, so changing it like that shouldn't be an issue. I think this sounds like a good option. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On 18 February 2011 00:56, Johan Tibell johan.tib...@gmail.com wrote: On Thu, Feb 17, 2011 at 2:43 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Thu, Feb 17, 2011 at 11:53 AM, Bas van Dijk v.dijk@gmail.com wrote: Then we can use the TimeoutKey as our Unique (Note that a TimeoutKey is actually a newtype for a Unique): That should be fine. It's not a public API, so changing it like that shouldn't be an issue. I think this sounds like a good option. Currently I created a new function registerTimeoutWithKey and wrote registerTimeout in terms of it. I also exported registerTimeoutWithKey from System.Event.Manager and System.Event. This isn't necessary so I can easily change it back. However maybe it's useful on its own. It does require a library proposal so I have to think it over. The changes are only minimal: -- Registering interest in timeout events -- | Register a timeout in the given number of microseconds. The -- returned 'TimeoutKey' can be used to later unregister or update the -- timeout. The timeout is automatically unregistered after the given -- time has passed. Note that: -- -- @registerTimeout mgr us cb = 'registerTimeoutWithKey' mgr us $ \_ - cb@ registerTimeout :: EventManager - Int - TimeoutCallback - IO TimeoutKey registerTimeout mgr us cb = registerTimeoutWithKey mgr us $ \_ - cb -- | Like 'registerTimeout' but the 'TimeoutCallback' is given the 'TimeoutKey'. registerTimeoutWithKey :: EventManager - Int - (TimeoutKey - TimeoutCallback) - IO TimeoutKey registerTimeoutWithKey mgr us f = do !key - newUnique (emUniqueSource mgr) let tk = TK key cb = f tk if us = 0 then cb else do now - getCurrentTime let expTime = fromIntegral us / 100.0 + now -- We intentionally do not evaluate the modified map to WHNF here. -- Instead, we leave a thunk inside the IORef and defer its -- evaluation until mkTimeout in the event loop. This is a -- workaround for a nasty IORef contention problem that causes the -- thread-delay benchmark to take 20 seconds instead of 0.2. atomicModifyIORef (emTimeouts mgr) $ \f - let f' = (Q.insert key expTime cb) . f in (f', ()) wakeManager mgr return tk The timeout function is now defined as: newtype Timeout = Timeout TimeoutKey instance Exception Timeout timeout :: Int - IO a - IO (Maybe a) timeout usecs f | usecs 0 = fmap Just f | usecs == 0 = return Nothing | otherwise = do myTid - myThreadId Just mgr - readIORef eventManager mask $ \restore - do key - registerTimeoutWithKey mgr usecs $ \key - throwTo myTid $ Timeout key let unregTimeout = M.unregisterTimeout mgr key (restore (fmap Just f) = \mb - unregTimeout return mb) `catch` \e - case fromException e of Just (Timeout key') | key' == key - return Nothing _ - unregTimeout throwIO e Benchmarks are coming... Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On Thu, Feb 17, 2011 at 4:09 PM, Bas van Dijk v.dijk@gmail.com wrote: Currently I created a new function registerTimeoutWithKey and wrote registerTimeout in terms of it. I also exported registerTimeoutWithKey from System.Event.Manager and System.Event. This isn't necessary so I can easily change it back. However maybe it's useful on its own. I say only export a more general function (under the old name). It does require a library proposal so I have to think it over. It doesn't. System.Event isn't a public API. Doesn't mean that you don't have to think it over thought. ;) Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On 18 February 2011 01:16, Johan Tibell johan.tib...@gmail.com wrote: On Thu, Feb 17, 2011 at 4:09 PM, Bas van Dijk v.dijk@gmail.com wrote: Currently I created a new function registerTimeoutWithKey and wrote registerTimeout in terms of it. I also exported registerTimeoutWithKey from System.Event.Manager and System.Event. This isn't necessary so I can easily change it back. However maybe it's useful on its own. I say only export a more general function (under the old name). Agreed. It does require a library proposal so I have to think it over. It doesn't. System.Event isn't a public API. Doesn't mean that you don't have to think it over thought. ;) Why is it not public? It is listed in the base API docs: http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-Event.html Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On Thu, Feb 17, 2011 at 4:19 PM, Bas van Dijk v.dijk@gmail.com wrote: Why is it not public? It is listed in the base API docs: http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-Event.html Because it's not explicitly designed to be. Eventually it should be. We designed it as a separate library and didn't change the names when merging it into GHC (that was painful enough as it was). I did send a patch to add a comment to that affect to the GHC mailing list but perhaps it never got applied. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On 18 February 2011 01:28, Johan Tibell johan.tib...@gmail.com wrote: On Thu, Feb 17, 2011 at 4:19 PM, Bas van Dijk v.dijk@gmail.com wrote: Why is it not public? It is listed in the base API docs: http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-Event.html Because it's not explicitly designed to be. Ok, that will make changing it a bit easier. Thanks, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Web Framework Happstack 6 Released
I don't know who said it first, but I'm repeating it. 2011 is going to be the tipping point year for haskell web frameworks. Thanks Jeremy! 2011/2/17 Jeremy Shaw jer...@n-heptane.com: Hello, I am pleased to announce the release of Happstack 6. We fully recommend that all Happstack users migrate to the new release. Happstack is a high-performance Haskell web framework. It has high-level functionality for routing requests, extracting parameters, manipulating responses, serving static file contents, compression responses, and more. It includes an integrated HTTP server and a native RAM-cloud database system known as MACID. This allows you to deploy your web application with out having to configure apache, php, mysql, memcached, etc! Install instructions can be found here: http://happstack.com/download If you are porting existing applications you should check out the Happstack 6 migration guide: http://code.google.com/p/happstack/wiki/Happstack6Migration Porting should be pretty straight-forward. Despite the massive reorganization, the exports from Happstack.Server are largely the same. What's Exciting! The focus of this release has been happstack-server. The primary goal was to make happstack-server much easier to learn and to use. This includes: 1. improving the overall organization of the library 2. greatly improving the documentation 3. making it easier to install 4. ensuring that the server provides fast, reliable performance 5. making it easier for new (and old) developers to understand and get started If you have looked at Happstack before and found it too difficult to understand, I highly recommend you take another look. The new organization and documentation make it far easier to understand. More Logical Organiation In prior versions, the Happstack.Server.SimpleHTTP module contained just about everything, with little organization, and no real differentiation between the external API and the library internals. In Happstack 6, SimpleHTTP has been refactored into numerous, smaller modules. The internals have been moved into Happstack.Server.Internal.* so that they are not leaking into the external API. This should make it much easier to find what you are looking for, and prevent you from accidently running across internal things like the WebT monad, which you do not really need to know anything about. Better Documentation The API documentation for happstack-server is also much better. All external API functions should now have good haddock documentation with many inline examples. However, learning a new library by studying the API documentation can still be pretty frustrating. So we also have the brand new Happstack Crash Course. http://happstack.com/docs/crashcourse/index.html. The Happstack Crash Course covers a vast majority of the happstack-server API. It covers the API in a logical manner and includes many downloadable, runnable examples. It is intended to be read start to finish, and to also be usable as a reference guide for specific How do I do XXX questions. Additionally, the guestbook example has been updated to a cleaner, more modern style of Happstack coding. It also has more comments/haddock documentation. Better API -- During the process of documenting Happstack, many small improvements where made to the API. Once you try to document something stupid you realize how stupid it is and decided it would be good to fix it first ;) For example, the Cookie API now makes it more obvious how to create session cookies vs persistent cookies. And makes it obvious how to expire a cookie. The functions for looking up values in the query string and require body no longer require the use of the RqData monad. You can use the look* functions directly in the ServerPart monad. If you do choose to use RqData, it now has an Applicative instance which can accummulate and report lookup errors. (http://happstack.blogspot.com/2010/10/is-rqdata-monad-still-needed.html) There are a bunch of other improvements to request data handling documented here, http://happstack.com/docs/crashcourse/RqData.html. Easier Install -- In order to make Happstack easier to install we have removed as many dependencies as possible. happstack-data no longer depends on happstack-util, which makes it easier to install happstack-data or happstack-state with out the rest of the framework. HSP and HStringTemplate support has been moved into *optional* happstack-hsp and happstack-hstringtemplate packages. New Features Happstack also has a number of new features including: - support for Heist templates (http://happstack.com/docs/crashcourse/Templates.html#helloheist) - support for Hamlet templates - improved environment for extracting query string and form values
Re: [Haskell-cafe] Faster timeout but is it correct?
On 18 February 2011 01:09, Bas van Dijk v.dijk@gmail.com wrote: Benchmarks are coming... Here are some preliminary benchmarks. I used the latest GHC HEAD (7.1.20110217) build for performance. Because I wanted to finish the build of ghc before I went to bed I used a faster machine than my laptop. So the results should not be compared to my previous results. PC specs: CPU: Intel Core 2 Duo 3Ghz. with 6MB cache OS: An up to date 64bit Ubuntu 10.10 First of all the implementations: The current: data Timeout = Timeout Unique timeout :: Int - IO a - IO (Maybe a) timeout n f | n 0= fmap Just f | n == 0= return Nothing | otherwise = do pid - myThreadId ex - fmap Timeout newUnique handleJust (\e - if e == ex then Just () else Nothing) (\_ - return Nothing) (bracket (forkIO (threadDelay n throwTo pid ex)) (killThread) (\_ - fmap Just f)) The new: newtype Timeout = Timeout ThreadId timeout :: Int - IO a - IO (Maybe a) timeout n f | n 0= fmap Just f | n == 0= return Nothing | otherwise = do myTid - myThreadId uninterruptibleMask $ \restore - do tid - unsafeUnmask $ forkIO $ do tid - myThreadId threadDelay n throwTo myTid $ Timeout tid (restore (fmap Just f) = \mb - killThread tid return mb) `catch` \e - case fromException e of Just (Timeout tid') | tid' == tid - return Nothing _ - killThread tid throwIO e The event-manager based: newtype Timeout = Timeout TimeoutKey timeout :: Int - IO a - IO (Maybe a) timeout usecs f | usecs 0 = fmap Just f | usecs == 0 = return Nothing | otherwise = do myTid - myThreadId Just mgr - readIORef eventManager mask $ \restore - do key - registerTimeoutWithKey mgr usecs $ \key - throwTo myTid $ Timeout key let unregTimeout = M.unregisterTimeout mgr key (restore (fmap Just f) = \mb - unregTimeout return mb) `catch` \e - case fromException e of Just (Timeout key') | key' == key - return Nothing _ - unregTimeout throwIO e The benchmarks: (These should really be extended!) willTimeout = shouldTimeout $ timeout 1 (threadDelay oneSec) wontTimeout = shouldNotTimeout $ timeout oneSec (return ()) nestedTimeouts = shouldTimeout $ timeout 10 $ shouldNotTimeout $ timeout (2*oneSec) $ threadDelay oneSec externalException = do (tid, wait) - fork $ timeout oneSec (threadDelay oneSec) threadDelay 500 throwTo tid MyException r - wait case r of Left e | Just MyException - fromException e - return () _ - error MyException should have been thrown! Results: The benchmarks were build with -O2 and -threaded and run without RTS options (So no -N2, I may do that later but AFAIK the RTS will automatically find the number of cores) willTimeout/old 24.34945 us1.0 x willTimeout/new 26.91964 us0.9 x (large std dev: 5 us) willTimeout/event 12.94273 us1.9 x :-) wontTimeout/old 16.25766 us1.0 x wontTimeout/new 637.8685 ns 25.5 x :-) wontTimeout/event 1.565311 us 10.4 x :-) externalException/old 10.28582 ms1.0 x externalException/new 9.960918 ms1.0 x externalException/event 10.25484 ms1.0 x nestedTimeouts/old 108.1759 ms1.0 x nestedTimeouts/new 108.4585 ms1.0 x nestedTimeouts/event109.9614 ms1.0 x Preliminary conclusions: I think the most important benchmark is wontTimeout because AFAIK that's the most common situation. As can be seen, the new implementation is 25 times faster than the old one. The event-manager based implementation is 10 times faster than the old one but not quite as fast as the new one. Although the event-manager based timeout has to do less work the new one probably exploits parallelism because it forks a thread to do part of its work. A nice result is that in my previous efforts I couldn't achieve speedups in the willTimeout benchmark. Fortunately the event-manager based implementation is twice as fast as the original. Further work: I will brainstorm on this some more and update my patches for base during the weekend. Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On Thu, Feb 17, 2011 at 5:01 PM, Bas van Dijk v.dijk@gmail.com wrote: willTimeout/old 24.34945 us 1.0 x willTimeout/new 26.91964 us 0.9 x (large std dev: 5 us) willTimeout/event 12.94273 us 1.9 x :-) wontTimeout/old 16.25766 us 1.0 x wontTimeout/new 637.8685 ns 25.5 x :-) wontTimeout/event 1.565311 us 10.4 x :-) I find this very surprising. Both new and event eventually ends up using the event manager in the end. One via threadDelay (which calls registerTimeout) and one directly via registerTimeout. The difference should be that new also spawns a thread. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] `cabal install darcs` fail !
cabal update cabal install darcs .. Installing library in /home/sw2wolf/.cabal/lib/hashed-storage-0.5.5/ghc-6.10.4 Registering hashed-storage-0.5.5... Reading package info from dist/installed-pkg-config ... done. Writing new package config file... done. cabal: Error: some packages failed to install: darcs-2.5.1 depends on haskeline-0.6.3.2 which failed to install. haskeline-0.6.3.2 failed during the configure step. The exception was: ExitFailure 1 uname -a FreeBSD mybsd.zsoft.com 8.1-RELEASE FreeBSD 8.1-RELEASE #1: Wed Sep 8 09:07:54 CST 2010 r...@mybsd.zsoft.com:/media/G/usr/obj/media/G/usr/src/sys/MYKERNEL i386 It seems that the cabal is NOT very strong, isnot it ? - e^(π.i) + 1 = 0 -- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-darcs-fail-tp3390542p3390542.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
