- Haskell-Cafe - Haskell.org

help with safecopy + acid-state
by Johannes Waldmann 31 Jan '12

31 Jan '12

Dear all, I can't quite get safecopy to work with acid-state: old version of code : data T = T Foo $(deriveSafeCopy 0 'base ''T) new version : data T_orig = T_orig Foo $(deriveSafeCopy 0 'base ''T_orig) data T = T Foo Bar $(deriveSafeCopy 0 'extension ''T) instance Migrate T where type MigrateFrom T = T_Orig ... but when my (new) application reads the state from disk (written by the old application) I get "Could not parse saved checkpoint due to the following error: Failed reading: Duplicate version tags: [0,0]" When I change the version number in deriveSafeCopy, I get "Failed reading: safecopy: Map: Cannot find getter associated with this version number: Version {unVersion = 2}" I don't even know where the "2" comes from. Any hints appreciated - J.W.

3 5

Re: [Haskell-cafe] [Haskell] ANNOUNCE multiarg - parser combinators for command line parsing
by Henning Thielemann 31 Jan '12

31 Jan '12

On Sun, 29 Jan 2012, Simon Meier wrote: > I'm currently using Neil Mitchell's cmdargs package [1]. How does your > package compare to that? Last time I checked cmdargs it was not referential transparent. Is multiarg better in this respect?

3 2

Monad-control rant
by Mikhail Vorozhtsov 31 Jan '12

31 Jan '12

On 11/12/2011 07:34 AM, Bas van Dijk wrote: >> Are you going to release a new version of monad-control right away > > Not just yet. I've split `monad-control` into two packages: > > * `monad-control`: just exports `Control.Monad.Trans.Control`. This part is finished. > * `lifted-base`: wraps all modules of the `base` package which export `IO` computations and provides > lifted version instead. For example we have `Control.Exception.Lifted`, `Control.Concurrent.Lifted`, etc. > > As you can imagine the latter is a lot of boring work. Fortunately it's easy to do so will probably > not take a lot of time. BTW if by any chance you want to help out, that will be much appreciated! > > The repos can be found [here](https://github.com/basvandijk/lifted-base) Maybe I should elaborate on why I stopped using monad-control and rolled out my own version of lifted Control.Exception in monad-abort-fd package. I'm CC-ing the Cafe just in case someone else might be interested in the matter of IO lifting. Imagine we have a monad for multiprogramming with shared state: -- ContT with a little twist. Both the constructor and runAIO -- are NOT exported. newtype AIO s α = AIO { runAIO ∷ ∀ β . (α → IO (Trace s β)) → IO (Trace s β) } runAIOs ∷ MonadBase IO μ ⇒ s -- The initial state → [AIO s α] -- The batch of programs to run. -- If one program exits normally (without using -- aioExit) or throws an exception, the whole batch -- is terminated. → μ (s, Maybe (Attempt α)) -- The final state and the result. -- "Nothing" means deadlock or that -- all the programs exited with -- aioExit. runAIOs = liftBase $ mask_ $ ... bloody evaluation ... data Trace s α where -- Finish the program (without finishing the batch). TraceExit ∷ Trace s α -- Lift a pure value. TraceDone ∷ α → Trace s α -- A primitive to execute and the continuation. TraceCont ∷ Prim s α → (α → IO (Trace s β)) → Trace s β -- Primitive operations data Prim s α where -- State retrieval/modification PrimGet ∷ Prim s s PrimSet ∷ s → Prim s () -- Scheduling point. The program is suspended until -- the specified event occurs. PrimEv ∷ Event e ⇒ e → Prim s (EventResult e) -- Scheduling point. The program is suspended until the state -- satisfies the predicate. PrimCond ∷ (s → Bool) → Prim s () -- Run computation guarded with finalizer. PrimFin ∷ IO (Trace s α) → (Maybe α → AIO s β) → Prim s (α, β) -- Run computation guarded with exception handler. PrimHand ∷ IO (Trace s α) → (SomeException → AIO s α) → Prim s α aioExit ∷ AIO s α aioExit = AIO $ const $ return TraceExit aioAfter ∷ (s → Bool) → AIO s () aioAfter cond = AIO $ return . TraceCont (PrimCond cond) aioAwait ∷ Event e ⇒ e → AIO s (EventResult e) aioAwait e = AIO $ return . TraceCont (PrimEv e) runAIOs slices the programs at scheduling points and enqueues the individual pieces for execution, taking care of saving/restoring the context (finalizers and exception handlers). The Functor/Applicative/Monad/MonadBase/etc instances are pretty trivial: instance Functor (AIO s) where fmap f (AIO g) = AIO $ \c → g (c . f) instance Applicative (AIO s) where pure a = AIO ($ a) (<*>) = ap instance Monad (AIO s) where return = pure AIO g >>= f = AIO $ \c → g (\a → runAIO (f a) c) instance MonadBase IO (AIO s) where liftBase io = AIO (io >>=) instance MonadState s (AIO s) where get = AIO $ return . TraceCont PrimGet put s = AIO $ return . TraceCont (PrimSet s) instance MonadAbort SomeException (AIO s) where abort = liftBase . throwIO trace ∷ AIO s α → IO (Trace s α) trace (AIO g) = g (return . TraceDone) instance MonadRecover SomeException (AIO s) where recover m h = AIO $ return . TraceCont (PrimHand (trace m) h) instance MonadFinally (AIO s) where finally' m f = AIO $ return . TraceCont (PrimFin (trace m) f) -- finally m = fmap fst . finally' m . const -- No async exceptions in AIO instance MonadMask () (AIO s) where getMaskingState = return () setMaskingState = const id Now we have a problem: we can throw/catch exceptions and install finalizers in AIO, but we can't use Control.Exception.Lifted because we can't declare a MonadBaseControl instance for our "ContT with limited interface". So now, instead of trying to wrap IO control operations uniformly, I just reimplement them in terms of the classes I mentioned above (MonadAbort+MonadRecover+MonadFinally+MonadMask), for example: bracket ∷ (MonadFinally μ, MonadMask m μ) ⇒ μ α → (α → μ β) → (α → μ γ) → μ γ bracket acq release m = mask $ \restore → do a ← acq finally (restore $ m a) (release a) It requires more typing (more classes => more instances), but it works for a broader class of monads and I get proper side affects in finalizers for a bonus. The code is on Hackage (monad-abort-fd) and on the GitHub (https://github.com/mvv/monad-abort-fd/blob/master/src/Control/Monad/Excepti…)

4 24

TCP Server
by Alexander V Vershilov 31 Jan '12

31 Jan '12

Hello, café. Recently I asked about tcp server libraries [1] and there was only one answer haskell-scallable-server [2], but in that package there was some dependencies and server logic that are not good for my task. So I decided to make a library with skeletons for different types of tcp servers and a basic library to make server [3]. Now there is only warp based (simplified) tcp server. Main logic is: * handle new connection and start iteratee green thread * enumerator (library side) reads socket and send data into enumeratee (application side) * enumeratee consumes input and produces server command (now simply output) and push it into iteratee (server side) * iteratee server side reads command and performs action (now simply output command) It gives application possibility to store state in enumerator. My questions to community: 1). can you help to make code better ;) maybe there are some stupid mistakes 2). is there any ideas what thing can be add to the server to make it reusable And another thing that I want to add other types of server e.g. single threaded, with workers pool, or other types. And I want to ask what types of servers will be effective in haskell. [1] http://www.haskell.org/pipermail/haskell-cafe/2012-January/098594.html [2] https://github.com/jamwt/haskell-scalable-server [3] https://github.com/qnikst/TcpServers -- Alexander V Vershilov.

7 12

[ANNOUNCE] biostockholm 0.2
by Felipe Almeida Lessa 31 Jan '12

31 Jan '12

Hello! I'm pleased to announce the second major release of the biostockholm library! This library allows you to parse and render files in the Stockholm 1.0 format, which is used by Pfam, Rfam, Infernal and others for holding information about families of proteins or non-coding RNAs. http://hackage.haskell.org/package/biostockholm Despite this low increase in number from 0.1 to 0.2, this is actually a big rewrite of the library. Now we have: - An streaming interface similar to what SAX parsers provide. This allows you to consume Stockholm files using constant memory (80k in a simple case). - More test cases. It's able to consume its own pretty printed version of Rfam through the document interface, and is also capable of reading the full Rfam stockholm file (which has some huge families) through the streaming interface. - QuickCheck properties. Now we have three different QuickCheck properties covering almost everything. These have helped uncover some tricky bugs that were never found before. However, two of these three properties still don't pass, but I consider the failing examples that I've investigated just corner cases. Unfortunately, Stockholm lacks a formal specification. - Conduit interface. Besides a lazy I/O version, now there's a conduit interface. - Code much easier to read and reason about. - Fast enough: the streaming interface achieves 12 MiB/s for parsing, which is pretty nice considering that there are some known overheads on its implementation. For the tasks that biostockholm 0.1 already handled, biostockholm 0.2 tends to be slightly slower. However, biostockholm 0.2 is able to handle some previously impossible cases where an streaming solution is required. Cheers! -- Felipe.

1 1

strict version of Haskell - does it exist?
by Marc Weber 31 Jan '12

31 Jan '12

A lot of work has been gone into GHC and its libraries. However for some use cases C is still preferred, for obvious speed reasons - because optimizing an Haskell application can take much time. Is there any document describing why there is no ghc --strict flag making all code strict by default? Wouldn't this make it easier to apply Haskell to some additional fields such as video processing etc? Wouldn't such a '--strict' flag turn Haskell/GHC into a better C/gcc compiler? Projects like this: https://github.com/thoughtpolice/strict-ghc-plugin show that the idea is not new. Eg some time ago I had to do some logfile analysis. I ended doing it in PHP because optimizing the Haskell code took too much time. Marc Weber

12 18

[Haskell Cafe] strict version of Haskell - does it exist?
by Doug McIlroy 31 Jan '12

31 Jan '12

> Is there any document describing why there is no ghc --strict flag > making all code strict by default? > Wouldn't such a '--strict' flag turn Haskell/GHC into a better C/gcc > compiler? I agree that a strict flag would turn Haskell into C--but that's a perversion of Haskell. Almost all Haskell code I write depends critically on laziness. Sure, there are little bits here and there that would run faster if I carefully decorated them with strict flags. But the genius of Haskell is architectural clarity, achieved in no small part by relegating nasty issues of sequencing to the implementation. If you even have to think once about what needs to be strict or non-strict, then non-strict is the only viable default. I can't imagine writing any interesting Haskell code that will successfully run all strict. Doug McIlroy

4 3

Invitation to connect on LinkedIn
by Sunny Basi 31 Jan '12

31 Jan '12

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Sunny Sunny Basi Software Development Engineer Intern at Amazon.com Greater Seattle Area Confirm that you know Sunny Basi: https://www.linkedin.com/e/uc6lxc-gy2lv1bv-z/isd/5727371010/HFPCz0eC/?hs=fa… -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/uc6lxc-gy2lv1bv-z/XvIdBwmueHfd6vFMPXXdLaqreCbl5oO… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

Speculative Parallelism
by Burak Ekici 31 Jan '12

31 Jan '12

Dear List, my question is in which cases, I could understand the speculative parallelism in parallel Haskell? Does the case in which all and the same number of created sparks are converted by both original and second generation strategies, speak of the speculative parallelism effect? If it does not, how can I prove the argument that indicating speculative parallelism could be exploited in second generation strategies while it is not possible to exploit when usages of original ones are in question? Kind regards, Burak.

1 0

space leak when repeatedly calling Control.Monad.State.Strict.modify
by Joey Hess 31 Jan '12

31 Jan '12

The attached test case quickly chews up hundreds of MB of memory. If modified to call work' instead, it runs in constant space. Somehow the value repeatedly read in from the file and stored in the state is leaking. Can anyone help me understand why? (ghc 7.0.4) -- see shy jo

3 4