Re: [Haskell-cafe] IterIO type restricted functions
At Wed, 29 Jun 2011 10:11:26 +1000, John Ky wrote: > > [1 ] > [1.1 ] > > Hi all, > > From the IterIO tutorial: > > enumFile' is like enumFile above, but type restricted to data in the lazy > ByteString format, which is more efficient than plain Strings. (enumFile > supports multiple types, but in this example there is not enough > information for Haskell to choose one of them, so we must use enumfile' or > use :: to specify a type explicitly. > > Which is fine, but shouldn't there also be iterHandle' and iterStream'? > > Also I'm guessing the f is a typo that should be F. Thanks, just fixed the typo in git. I guess the logic is that these are super-easy to define in your own code, so better not to pollute the namespace with lots of symbols. The same logic also applies to enumFile'. However, in testing I found that I often wanted something like enumFile' to prototype something quick and dirty, just to test from a file. So I added it as a convenience to myself. I don't have very strong feelings either way. If enumFile' is inconsistent, my inclination would be to get rid of enumFile' rather than add iterHandle' etc. That way, if someone wants to do everything in terms of strict byte strings, or text, or whatever, then can just define the primed versions to be whatever data format they prefer. I guess the reason it doesn't feel to horrible as-is is that enumFile is already a convenience function effectively combining openFile with enumHandle. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] attoparsec and vectors
On Tue, Jun 28, 2011 at 6:20 PM, Eric Rasmussen wrote: > It runs quickly, but I naively thought I could outperform it by reworking > "many" to build a vector directly, instead of having to build a list first > and then convert it to a vector: > > manyVec :: Alternative f => f a -> f (V.Vector a) > manyVec v = many_v > where many_v = some_v <|> pure V.empty > some_v = V.cons <$> v <*> many_v That's an O(n^2) loop, and a thunk leak to boot. If you don't know the size of the vector ahead of time, the only way I can think of to beat Vector.fromList is to use a mutable vector with a "highwater" mark, and double the size if you fill it. At the end, you'd use "unsafeFreeze" to turn the mutable vector into a pure one, and "unsafeTake" to truncate the vector into the correct size. For an example of a similar technique (minus the freezing part), I did a similar thing in the hashtables library: https://github.com/gregorycollins/hashtables/blob/master/src/Data/HashTable/Internal/Linear/Bucket.hs#L45 It's unlikely to be worth the extra effort except for extremely performance-critical code. G -- Gregory Collins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible bug in GHC 7.0.3
So this is definitely a GHC bug, but I think the problem is probably
triggered by this line:
instance Serializable a b => IResource a
I don't think this is a valid instance declaration without a functional
dependency on Serializable, as it's impossible to know which type 'b' to use
in the methods of IResource.
-- ryan
On Tue, Jun 28, 2011 at 3:43 AM, Alberto G. Corona wrote:
> I have an "'impossible' happened" error.
>
> The code may look a little bit convoluted but it is part of my real code.:
>
>
> - begin of code--
>
> {-# LANGUAGE FlexibleInstances, UndecidableInstances
>, MultiParamTypeClasses
> #-}
>
> class Serializable a b
>
>
> class IResource a --The rest of the instance definitions does not
> matter for the error
>
>
> instance Serializable a b => IResource a
>
> data DBRef a= DBRef String a
>
>
> instance (IResource a) => Read (DBRef a)
>
>
> data Votation a= Votation{
> content :: DBRef a
> } deriving (Read)
>
> --- end of code ---
>
> gives the following error at compilation time:
>
> tests>runghc impossiblelloop.hs
> ghc: panic! (the 'impossible' happened)
> (GHC version 7.0.3 for i386-unknown-mingw32):
> solveDerivEqns: probable loop
> (impossiblelloop.hs:20:13-16 main:Main.$fReadVotation{v rhI} [a{tv abB}
> [tv]
> ] base:GHC.Read.Read{tc 2d} [main:Main.Votation{tc rbo}
>
>a{tv abB} [tv]] = [base:GHC.Read.Read{tc 2d}
>
> (main:Main.DBRef{tc
> rbu}
>
>a{tv abB} [tv])])
> [[main:Main.Serializable{tc rbA} a{tv abB} [tv] b{tv ajE} [tcs]]]
>
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
>
> ___
> 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] IterIO type restricted functions
Hi all, >From the IterIO tutorial: enumFile' is like enumFile above, but type restricted to data in the lazy ByteString format, which is more efficient than plain Strings. (enumFile supports multiple types, but in this example there is not enough information for Haskell to choose one of them, so we must use enum*f*ile' or use :: to specify a type explicitly. Which is fine, but shouldn't there also be iterHandle' and iterStream'? Also I'm guessing the *f* is a typo that should be *F*. Cheers, -John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] attoparsec and vectors
Hi everyone, I have a task that involves parsing a flat-file into a vector from the Data.Vector package. In the interest of keeping things simple, I first used Attoparsec.Text's version of "many" and then converted the resulting list to a vector: import qualified Data.Vector as V import Data.Attoparsec.Text as A import Control.Applicative getData = do results <- A.many someParser return (V.fromList results) It runs quickly, but I naively thought I could outperform it by reworking "many" to build a vector directly, instead of having to build a list first and then convert it to a vector: manyVec :: Alternative f => f a -> f (V.Vector a) manyVec v = many_v where many_v = some_v <|> pure V.empty some_v = V.cons <$> v <*> many_v Unfortunately, manyVec either quickly leads to a stack space overflow, or it takes an enormous amount of time to run. Does anyone know of a better way to build up a vector from parsing results? Thanks for any tips or insight, Eric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exclusive mode in openFile
On 28 June 2011 18:56, Gracjan Polak wrote: > Anyway, where do I find an 'openFileShared' function? Packages unix/Win32 do > not > have obvious leads... Perhaps the functions in System.Posix.IO do what you want? http://hackage.haskell.org/packages/archive/unix/2.4.2.0/doc/html/System-Posix-IO.html. The equivalent on the Win32 side is CreateFile: http://hackage.haskell.org/packages/archive/Win32/2.2.0.2/doc/html/System-Win32-File.html There is a way to create a Handle from a Fd (http://hackage.haskell.org/packages/archive/base/latest/doc/html/GHC-IO-Handle-FD.html#v:fdToHandle), but I'm not sure if there is an equivalent to build a Handle from a Win32 HANDLE... Hope those pointers help... Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem building with Cabal + TH + Library with FFI to C++ via C Wrapper
Dear Cafe, I have recently run into a very annoying issue that I was not able to get around. I have a local package that makes use of the snappy compression library, which boasts bindings to C++ through a C wrapper. Everything compiles fine with ghc --make, but cabal install hits a wall when TemplateHaskell kicks in and decides to load the entire dependency chain. Here is the important bit of the error message I get after running "cabal install" Loading package snappy-0.2.0.0 ... linking ... ghc: /home/ubuntu/.cabal/lib/snappy-0.2.0.0/ghc-7.0.3/HSsnappy-0.2.0.0.o: unknown symbol `_ZTV8BSSource' ghc: unable to load package `snappy-0.2.0.0' I'm quite certain all the libs are in PATH. "cabal install snappy" installs fine when typed separately by itself and everything works fine (the program works, including compression via snappy) when I compile my local package with ghc --make. The problem only occurs on a Ubuntu 64-bit server, and I wasn't able to replicate the issue on my local OS X box. On my local, cabal install works just fine. I did find a previous note on Cafe with the exact same problem, but no solution was posted at the time: http://www.haskell.org/pipermail/haskell-cafe/2010-December/087748.html Any help is much appreciated. Cheers, Ozgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation Failed: Haskell Platform 2011.2.0.1-i386 for OS X
On Tue, Jun 28, 2011 at 11:14 AM, Tom Murphy wrote: > On 6/28/11, Jason Dagit wrote: >> >> I'd try asking on StackOverflow. I think the people who know the >> answer might be watching there instead of here. >> > > > Really? I had thought that everyone who was on SO was on here also. The operative word here being "watching" :) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation Failed: Haskell Platform 2011.2.0.1-i386 for OS X
On 6/28/11, Jason Dagit wrote: > > I'd try asking on StackOverflow. I think the people who know the > answer might be watching there instead of here. > Really? I had thought that everyone who was on SO was on here also. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exclusive mode in openFile
On Tue, Jun 28, 2011 at 13:56, Gracjan Polak wrote: > What was the rationale behind such strict non-sharing policy? The obvious rationale is that it helps maintain the illusion of referential integrity within the process. (Outside is a lost cause, but operations on different file handles are assumed to not affect each other.) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exclusive mode in openFile
Max Bolingbroke hotmail.com> writes: > This behaviour is part of the Haskell 98 specification (section > 21.2.3, http://www.haskell.org/onlinereport/io.html): Thanks for the explanation. Such sharing behavior should be mentioned in documentation: http://hackage.haskell.org/packages/archive/haskell98/latest/doc/html/IO.html#v:openFile What was the rationale behind such strict non-sharing policy? Anyway, where do I find an 'openFileShared' function? Packages unix/Win32 do not have obvious leads... > > """ > Implementations should enforce as far as possible, at least locally to > the Haskell process, multiple-reader single-writer locking on files. > That is, there may either be many handles on the same file which > manage input, or just one handle on the file which manages output. If > any open or semi-closed handle is managing a file for output, no new > handle can be allocated for that file. > """ > > I've been bitten by this before and don't like it. It would be > possible for GHC to enforce Unix semantics instead (there are > appropriate flags to CreateFile that get those semantics on Windows), > which would support more use cases. This change would have to be > carefully thought through, and the report would have to be amended. > > Cheers, > Max > -- Gracjan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Enumerators, Enumeratees and Iterators
On Mon, Jun 27, 2011 at 7:21 PM, Sævar Berg wrote: > > The first question is, I think, to be solved with enumeratees but I can't > really grok how. > Let's say I have an iteratee that consumes all input. Is it possible to > implement an enumeratee or something else to stick between the enumerator > and the iteratee to basically modify the input to the iteratee to only be a > part of the input? > Yes. You would want to use an enumeratee. Consider the following (based on the Enumerator package). It checks each element of the stream against a Set. If the element is in the set, then we do not forward the element to the inner iteratee. If the element is not in the set, we insert it and forward it to the inner iteratee. We "need" loop to carry the Set's state around. unique :: forall a m b . (Ord a, Monad m) => Enumeratee a a m b unique = loop Set.empty where loop :: (Ord a, Monad m) => Set a -> Enumeratee a a m b loop seen step@(Continue k) = continue go where go :: (Ord a, Monad m) => Stream a -> Iteratee a m (Step a m b) go EOF = return step go (Chunks (a:as)) = do (if (a `member` seen) then k $ Chunksas-- drop a if already seen else k $ Chunks (a:as)) -- keep a if not seen >>== loop (a `Set.insert` seen) go ch = (k ch >>== loop seen) loop seen step = return step > > Something like this: > > enumFile "someFile" && printFileLines -- prints file with prepended line > numbers > enumFile "someFile" ?? onlyGet10Lines && printFileLines -- print only 10 > lines > > The second question could actually have an application in the server I'm > writing. I was wondering if it was possible to write iteratees/enumerators > that would only generate/consume when a certain something was the next chunk > to be processed? It's a bit hard to explain, but let me try to give you an > example. > Perhaps, but it might be tricky depending on how much you /need/ the certain something to be a Chunk. Look at the 'unique' example above. Notice how we're pattern matching against a Chunk and its inner list. This would be the basis for your conditional matching. I would suggest that you don't want your "certain something" to be a chunk, but an element of the stream (i.e, one of the xs contained in Chunk xs) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible bug in GHC 7.0.3
Reported: http://hackage.haskell.org/trac/ghc/ticket/5287 2011/6/28 Alberto G. Corona > > 2011/6/28 Jason Dagit > >> On Tue, Jun 28, 2011 at 3:43 AM, Alberto G. Corona >> wrote: >> > I have an "'impossible' happened" error. >> > The code may look a little bit convoluted but it is part of my real >> code.: >> >> I don't know why it's crashing, but did you already report it as a >> bug? If not, you definitely should. >> >> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug >> >> That URL should have the info you need to report it. >> >> Jason >> > > Not published yet. I wanted to publish it in the list before reporting the > bug. Just in case anyone tell something interesting about it. A sorter > expression that produces the same bug or something similar. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exclusive mode in openFile
On 28 June 2011 17:50, Gracjan Polak wrote: > It seems I'm not allowed to open same file both for writing and for reading: This behaviour is part of the Haskell 98 specification (section 21.2.3, http://www.haskell.org/onlinereport/io.html): """ Implementations should enforce as far as possible, at least locally to the Haskell process, multiple-reader single-writer locking on files. That is, there may either be many handles on the same file which manage input, or just one handle on the file which manages output. If any open or semi-closed handle is managing a file for output, no new handle can be allocated for that file. """ I've been bitten by this before and don't like it. It would be possible for GHC to enforce Unix semantics instead (there are appropriate flags to CreateFile that get those semantics on Windows), which would support more use cases. This change would have to be carefully thought through, and the report would have to be amended. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible bug in GHC 7.0.3
On Tue, Jun 28, 2011 at 3:43 AM, Alberto G. Corona wrote: > I have an "'impossible' happened" error. > The code may look a little bit convoluted but it is part of my real code.: I don't know why it's crashing, but did you already report it as a bug? If not, you definitely should. > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug That URL should have the info you need to report it. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation Failed: Haskell Platform 2011.2.0.1-i386 for OS X
On Mon, Jun 27, 2011 at 10:33 AM, John Velman wrote: > I'm running OS X 10.6.7, XCode 3.2.5. When I try to install "The Haskell > Platform 2011.2.0.1 for Mac OS X 10.6 (Snow Leopard)" it goes all the way > through to "running package scripts", then says "installation failed" > > I did two separate downloads, and tried the first installation two time, > the second download one time. Same result all three times. > > Is this a problem with the package, or ? Any suggestions? I'd try asking on StackOverflow. I think the people who know the answer might be watching there instead of here. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Exclusive mode in openFile
Hi all, It seems I'm not allowed to open same file both for writing and for reading: Prelude System.IO> f_out <- openFile "mylog.log" AppendMode Prelude System.IO> f_in <- openFile "mylog.log" ReadMode *** Exception: mylog.log: openFile: resource busy (file is locked) Usage scenario: I use hslogger to write to logs, but I'd like to read parts of these logs *from inside same Haskell application*. How do I get around exclusive mode in openFile? -- Gracjan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Enumerators, Enumeratees and Iterators
If I've understood it correctly, "concurrent" is similar to functions discussed here: http://www.haskell.org/pipermail/haskell-cafe/2011-April/091474.html and here http://www.haskell.org/pipermail/haskell-cafe/2011-January/088319.html 2011/6/28 Ertugrul Soeylemez > Sævar Berg wrote: > > > The first question is, I think, to be solved with enumeratees but I can't > > really grok how. > > Let's say I have an iteratee that consumes all input. Is it possible to > > implement an enumeratee or something else to stick between the enumerator > > and the iteratee to basically modify the input to the iteratee to only be > a > > part of the input? > > Yes, this is an enumeratee. An enumeratee is neither a data producder > nor a consumer. It is an iteratee, which feeds another iteratee with > input based on its own input, so it acts like a kind of map operation. > > > > enumFile "someFile" && printFileLines -- prints file with prepended line > > numbers > > enumFile "someFile" ?? onlyGet10Lines && printFileLines -- print only 10 > > lines > > In fact an enumeratee can split the input stream into lines. Another > one can zip the stream with a list. A final one can take 10 lines from > the stream. The code would look like this (in the 'enumerator' > package): > >enumFile "myFile.txt" $$ >lines =$ >zipWithList [1..] =$ >take 10 =$ >printLines > > where > >lines :: Monad m => Enumeratee Text Text m b >zipWithList :: Monad m => [a'] -> Enumeratee a (a, a') m b >take:: Monad m => Int -> Enumeratee a a m b >printLines :: MonadIO m => Iteratee (Int, Text) m () > > This is how I would do it. > > > > The second question could actually have an application in the server > > I'm writing. I was wondering if it was possible to write > > iteratees/enumerators that would only generate/consume when a certain > > something was the next chunk to be processed? > > You want concurrent iteratees here. As far as I know in the > 'enumerator' package there is no builtin way to do it (you may be > luckier in the 'iteratee' package, but I don't know). However, I think > it should be possible to write a 'concurrent' function, if the iteratees > in question all have the same input type: > >concurrent :: Monad m => [Step a m b] -> Iteratee a m [b] > > A version, which doesn't collect the results is probably much easier to > write: > >concurrent_ :: Monad m => [Step a m b] -> Iteratee a m () > > > Greets, > Ertugrul > > > -- > nightmare = unsafePerformIO (getWrongWife >>= sex) > http://ertes.de/ > > > > ___ > 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] What is a "simple pattern binding"?
On 26/06/2011 09:31, Paterson, Ross wrote: If this is the case, then multiple sentences in the 2010 report don't make sense, though the way in which they don't make sense sort of depends on what "simple pattern binding" means. Indeed, the Report has two problems: Sections 4.4.3.2 and 4.5.5 have different definitions of "simple pattern". This has been there since section 4.5.5 (Monomorphism Restriction) was added in Haskell 1.1. But then the only technical use of the term is in section 4.5.5. When the definition of declaration group (section 4.5.1) was changed in Haskell 2010 to break dependencies on type signatures, Rule 1 of the Monomorphism Restriction (section 4.5.5), while not incorrect, became partially redundant and overly complex. It could have been simplified along the lines you describe. Indeed, I have on my ToDo list for the Haskell report: Fix confusion about "simple pattern binding" terminology in Sec 4. we should try to fix this in Haskell 2012. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cleaner way to write code and handle errors?
Thanks Jonas,
I feel much better already:
import Control.Concurrent
import Control.Exception
import Control.Monad
import Network
import System.IO
import System.IO.Error (isEOFError)
main = withSocketsDo $ do
sListen <- listenOn (PortNumber 8000)
putStrLn "Listening on Port 8000"
forkIO $ forever $ do
(sSession, hostname, port) <- accept sListen
putStrLn ("Connected to " ++ hostname ++ ":" ++ show port)
forkIO $ echoLines sSession
putStrLn "Press to quit."
exitOnEof
echoLines h = try (hGetLine h) >>= either
(\e -> if isEOFError e then print e else ioError e)
(putStrLn >=> const (echoLines h))
exitOnEof = try getLine >>= either
(\e -> unless (isEOFError e) $ ioError e)
(const exitOnEof)
I also worked out I didn't void by making processLines (now echoLines h) be
forkIO's argument rather than forkIO's result.
Cheers,
-John
2011/6/28 Jonas Almström Duregård
> There is the void function in Control.Monad:
>
> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Monad.html#v:void
>
> Instead of using return () you can just use void processLine.
>
> Also some people like to use the either function instead of matching on
> Left/Right. In this case you can also avoid introducing a few names:
>
>let processLine = void $ forkIO $
> try (hGetLine sSession) >>= either
> (\e -> if isEOFError e
> then print e
> else ioError e)
>(putStrLn >=> const processLine)
>
>
> On 28 June 2011 12:58, John Ky wrote:
> > Hi Eric, Ivan,
> > On 28 June 2011 18:32, Erik de Castro Lopo wrote:
> >>
> >> The hlint program would have flagged both of those and possibly
> >> others. See:
> >
> > Cool!
> > It didn't flag either for me, but it recommended replacing ++ (show port)
> > with ++ show port, if then else with unless, putStrLn (show x) with print
> x,
> > and do stuff with stuff.
> > All useful to know.
> > On 28 June 2011 18:16, Ivan Lazar
> > Miljenovic wrote:
> >>
> >> I don't think you need all those return () everywhere...
> >
> >
> > You're right. At some point I added it in to (try to) make the compiler
> > happy, but it must have been or become unnecessary.
> > I still need two though because forkIO (and therefore my processLine
> > function) returns IO ThreadId, but the last line for do notation must be
> > return () (see below).
> > On 28 June 2011 18:16, Ivan Lazar
> > Miljenovic wrote:
> >>
> >> And at the end, why do you do "line <- getLine" when you don't use the
> >> result?
> >
> > Oh that. I was trying to figure out a way to terminate by program. I've
> > now changed it to exit on EOF.
> > Here is my second attempt. Is it much better?:
> >
> > import Control.Concurrent
> > import Control.Exception
> > import Control.Monad
> > import Network
> > import System.IO
> > import System.IO.Error (isEOFError)
> > main = withSocketsDo $ do
> > sListen <- listenOn (PortNumber 8000)
> > putStrLn "Listening on Port 8000"
> > forkIO $ forever $ do
> > (sSession, hostname, port) <- accept sListen
> > putStrLn ("Connected to " ++ hostname ++ ":" ++ show port)
> > let processLine = forkIO $ do
> > lineResult <- try (hGetLine sSession)
> > case lineResult of
> > Right line -> do
> > putStrLn line
> > processLine
> > return ()
> > Left e -> if isEOFError e
> > then print e
> > else ioError e
> > processLine
> > return()
> > putStrLn "Press to quit."
> > let processStdIn = do
> > lineResult <- try getLine
> > case lineResult of
> > Right line -> processStdIn
> > Left e -> unless (isEOFError e) $ ioError e
> > processStdIn
> >
> > Thanks for the suggestions.
> > Cheers,
> > -John
> >
> > ___
> > 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] Cleaner way to write code and handle errors?
There is the void function in Control.Monad:
http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Monad.html#v:void
Instead of using return () you can just use void processLine.
Also some people like to use the either function instead of matching on
Left/Right. In this case you can also avoid introducing a few names:
let processLine = void $ forkIO $
try (hGetLine sSession) >>= either
(\e -> if isEOFError e
then print e
else ioError e)
(putStrLn >=> const processLine)
On 28 June 2011 12:58, John Ky wrote:
> Hi Eric, Ivan,
> On 28 June 2011 18:32, Erik de Castro Lopo wrote:
>>
>> The hlint program would have flagged both of those and possibly
>> others. See:
>
> Cool!
> It didn't flag either for me, but it recommended replacing ++ (show port)
> with ++ show port, if then else with unless, putStrLn (show x) with print
x,
> and do stuff with stuff.
> All useful to know.
> On 28 June 2011 18:16, Ivan Lazar
> Miljenovic wrote:
>>
>> I don't think you need all those return () everywhere...
>
>
> You're right. At some point I added it in to (try to) make the compiler
> happy, but it must have been or become unnecessary.
> I still need two though because forkIO (and therefore my processLine
> function) returns IO ThreadId, but the last line for do notation must be
> return () (see below).
> On 28 June 2011 18:16, Ivan Lazar
> Miljenovic wrote:
>>
>> And at the end, why do you do "line <- getLine" when you don't use the
>> result?
>
> Oh that. I was trying to figure out a way to terminate by program. I've
> now changed it to exit on EOF.
> Here is my second attempt. Is it much better?:
>
> import Control.Concurrent
> import Control.Exception
> import Control.Monad
> import Network
> import System.IO
> import System.IO.Error (isEOFError)
> main = withSocketsDo $ do
> sListen <- listenOn (PortNumber 8000)
> putStrLn "Listening on Port 8000"
> forkIO $ forever $ do
> (sSession, hostname, port) <- accept sListen
> putStrLn ("Connected to " ++ hostname ++ ":" ++ show port)
> let processLine = forkIO $ do
> lineResult <- try (hGetLine sSession)
> case lineResult of
> Right line -> do
> putStrLn line
> processLine
> return ()
> Left e -> if isEOFError e
> then print e
> else ioError e
> processLine
> return()
> putStrLn "Press to quit."
> let processStdIn = do
> lineResult <- try getLine
> case lineResult of
> Right line -> processStdIn
> Left e -> unless (isEOFError e) $ ioError e
> processStdIn
>
> Thanks for the suggestions.
> Cheers,
> -John
>
> ___
> 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] Cleaner way to write code and handle errors?
Hi Eric, Ivan,
On 28 June 2011 18:32, Erik de Castro Lopo wrote:
> The hlint program would have flagged both of those and possibly
> others. See:
>
Cool!
It didn't flag either for me, but it recommended replacing ++ (show
port)with ++
show port, if then else with unless, putStrLn (show x) with print x, and do
stuff with stuff.
All useful to know.
On 28 June 2011 18:16, Ivan Lazar Miljenovic
wrote:
> I don't think you need all those return () everywhere...
>
You're right. At some point I added it in to (try to) make the compiler
happy, but it must have been or become unnecessary.
I still need two though because forkIO (and therefore my processLine function)
returns IO ThreadId, but the last line for do notation must be return
()(see below).
On 28 June 2011 18:16, Ivan Lazar Miljenovic
wrote:
> And at the end, why do you do "line <- getLine" when you don't use the
> result?
>
Oh that. I was trying to figure out a way to terminate by program. I've
now changed it to exit on EOF.
Here is my second attempt. Is it much better?:
import Control.Concurrent
import Control.Exception
import Control.Monad
import Network
import System.IO
import System.IO.Error (isEOFError)
main = withSocketsDo $ do
sListen <- listenOn (PortNumber 8000)
putStrLn "Listening on Port 8000"
forkIO $ forever $ do
(sSession, hostname, port) <- accept sListen
putStrLn ("Connected to " ++ hostname ++ ":" ++ show port)
let processLine = forkIO $ do
lineResult <- try (hGetLine sSession)
case lineResult of
Right line -> do
putStrLn line
processLine
return ()
Left e -> if isEOFError e
then print e
else ioError e
processLine
return()
putStrLn "Press to quit."
let processStdIn = do
lineResult <- try getLine
case lineResult of
Right line -> processStdIn
Left e -> unless (isEOFError e) $ ioError e
processStdIn
Thanks for the suggestions.
Cheers,
-John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Possible bug in GHC 7.0.3
I have an "'impossible' happened" error.
The code may look a little bit convoluted but it is part of my real code.:
- begin of code--
{-# LANGUAGE FlexibleInstances, UndecidableInstances
, MultiParamTypeClasses
#-}
class Serializable a b
class IResource a --The rest of the instance definitions does not matter
for the error
instance Serializable a b => IResource a
data DBRef a= DBRef String a
instance (IResource a) => Read (DBRef a)
data Votation a= Votation{
content :: DBRef a
} deriving (Read)
--- end of code ---
gives the following error at compilation time:
tests>runghc impossiblelloop.hs
ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-mingw32):
solveDerivEqns: probable loop
(impossiblelloop.hs:20:13-16 main:Main.$fReadVotation{v rhI} [a{tv abB}
[tv]
] base:GHC.Read.Read{tc 2d} [main:Main.Votation{tc rbo}
a{tv abB} [tv]] = [base:GHC.Read.Read{tc 2d}
(main:Main.DBRef{tc rbu}
a{tv abB} [tv])])
[[main:Main.Serializable{tc rbA} a{tv abB} [tv] b{tv ajE} [tcs]]]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Enumerators, Enumeratees and Iterators
Sævar Berg wrote: > The first question is, I think, to be solved with enumeratees but I can't > really grok how. > Let's say I have an iteratee that consumes all input. Is it possible to > implement an enumeratee or something else to stick between the enumerator > and the iteratee to basically modify the input to the iteratee to only be a > part of the input? Yes, this is an enumeratee. An enumeratee is neither a data producder nor a consumer. It is an iteratee, which feeds another iteratee with input based on its own input, so it acts like a kind of map operation. > enumFile "someFile" && printFileLines -- prints file with prepended line > numbers > enumFile "someFile" ?? onlyGet10Lines && printFileLines -- print only 10 > lines In fact an enumeratee can split the input stream into lines. Another one can zip the stream with a list. A final one can take 10 lines from the stream. The code would look like this (in the 'enumerator' package): enumFile "myFile.txt" $$ lines =$ zipWithList [1..] =$ take 10 =$ printLines where lines :: Monad m => Enumeratee Text Text m b zipWithList :: Monad m => [a'] -> Enumeratee a (a, a') m b take:: Monad m => Int -> Enumeratee a a m b printLines :: MonadIO m => Iteratee (Int, Text) m () This is how I would do it. > The second question could actually have an application in the server > I'm writing. I was wondering if it was possible to write > iteratees/enumerators that would only generate/consume when a certain > something was the next chunk to be processed? You want concurrent iteratees here. As far as I know in the 'enumerator' package there is no builtin way to do it (you may be luckier in the 'iteratee' package, but I don't know). However, I think it should be possible to write a 'concurrent' function, if the iteratees in question all have the same input type: concurrent :: Monad m => [Step a m b] -> Iteratee a m [b] A version, which doesn't collect the results is probably much easier to write: concurrent_ :: Monad m => [Step a m b] -> Iteratee a m () Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cleaner way to write code and handle errors?
Ivan Lazar Miljenovic wrote: > I don't think you need all those return () everywhere... And at the > end, why do you do "line <- getLine" when you don't use the result? The hlint program would have flagged both of those and possibly others. See: http://community.haskell.org/~ndm/hlint/ 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
Re: [Haskell-cafe] Data Flow Programming in FP
On 20/06/11 15:45, Richard Senington wrote: Hi all, I have recently become interested in Dataflow programming and how it related to functional languages. I am wondering if the community has any advice on reading matter or other directions to look at. So far I have been looking through the FRP libraries, using Haskell functions with lazy lists for co-routines and the Essence of Dataflow Programming by Uustalu and Vene where they propose using co-monads. It looks as though Iteratees are also relevant but I have not got round to looking at them in detail yet. Have I missed anything? Regards RS ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Thank you for all the feedback, it has been very useful and I am still looking into these sources. RS ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cleaner way to write code and handle errors?
On 28 June 2011 18:08, John Ky wrote:
> Hi all,
> I'm practising my Haskell by writing a simple TCP echo server and finding
> that getting my program control to be succinct is rather tricky. In
> particular, I have return () everywhere, my error handling is verbose and
> I'm not entirely sure my recursion is the cleanest way syntactically to get
> my loops going and terminating.
> I must be doing something obviously un-Haskell-like.
> Any suggestions on how I can improve my code? Code below.
> Cheers,
> -John
>
> import Control.Concurrent
> import Control.Exception
> import Control.Monad
> import Network
> import System.IO
> import System.IO.Error (isEOFError)
> main = withSocketsDo $ do
> sListen <- listenOn (PortNumber 8000)
> putStrLn "Listening on Port 8000"
> forkIO $ forever $ do
> (sSession, hostname, port) <- accept sListen
> putStrLn ("Connected to " ++ hostname ++ ":" ++ (show port))
> let processLine = forkIO $ do
> lineResult <- try (hGetLine sSession)
> case lineResult of
> Right line -> do
> putStrLn line
> processLine
> return ()
> Left e ->
> if isEOFError e
> then putStrLn (show e)
> else do
> ioError e
> return ()
> return ()
> processLine
> return()
> line <- getLine
> return ()
I don't think you need all those return () everywhere... And at the
end, why do you do "line <- getLine" when you don't use the result?
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cleaner way to write code and handle errors?
Hi all,
I'm practising my Haskell by writing a simple TCP echo server and finding
that getting my program control to be succinct is rather tricky. In
particular, I have return () everywhere, my error handling is verbose and
I'm not entirely sure my recursion is the cleanest way syntactically to get
my loops going and terminating.
I must be doing something obviously un-Haskell-like.
Any suggestions on how I can improve my code? Code below.
Cheers,
-John
import Control.Concurrent
import Control.Exception
import Control.Monad
import Network
import System.IO
import System.IO.Error (isEOFError)
main = withSocketsDo $ do
sListen <- listenOn (PortNumber 8000)
putStrLn "Listening on Port 8000"
forkIO $ forever $ do
(sSession, hostname, port) <- accept sListen
putStrLn ("Connected to " ++ hostname ++ ":" ++ (show port))
let processLine = forkIO $ do
lineResult <- try (hGetLine sSession)
case lineResult of
Right line -> do
putStrLn line
processLine
return ()
Left e ->
if isEOFError e
then putStrLn (show e)
else do
ioError e
return ()
return ()
processLine
return()
line <- getLine
return ()
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
