http://blog.gmane.org/gmane.comp.lang.haskell.libraries hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17246 <pre>Hello First of all I'd like to say that I like vector-space and vector-space-opengl is something that I'd like to use together with OpenGL. So while using that library I found some things that can be useful for others, I think. While looking into OpenGL/TH.hs I found that it quite incomplete and I understand why. That suggestion at stackoverflow results in a bit boilerplate code: deriveScalar, deriveScalarAdditiveGroup, deriveScalarVectorSpace, deriveScalarAffineSpace :: [Name] -&gt; Q [Dec] deriveScalar ts = concat &lt;$&gt; forM decls (\qf -&gt; qf ts) where decls = [ deriveScalarAdditiveGroup , deriveScalarVectorSpace , deriveScalarAffineSpace , deriveScalarInnerSpace ] deriveScalarVectorSpace ts = concat &lt;$&gt; mapM f ts where f tn = do t &lt;- [t| $(conT tn) |] vs &lt;- [t| VectorSpace |] (AppT (ConT s) _) &lt;- [t| Scalar () |] -- dummy type to extract Scalar name (VarE h) &lt;- [e| (*^) |] -- refer to actual (*^) from VectorSpace e &lt;- [e| (*) |] -- (*) from Num return [ InstanceD [] (AppT vs t) [ TySynInstD s [t] t, ValD (VarP h) (NormalB e) [] ]] It's kinda partially checked and partially constructed. BTW, rather than depending on OpenGL its better to use Graphics.Rendering.OpenGL.Raw I think. Also there is types GLclampd and GLclampf (I suspect that they somehow related with OpenCL). While scalar types doesn't differ whether they are absolute whether they are not. Data.Tensor makes difference between Vertex and Vector. I suspect that made especially for this case: instance AffineSpace a =&gt; AffineSpace (Vertex2 a) where type Diff (Vertex2 a) = Vector2 (Diff a) I.e. Diff Vertex shouldn't be Vertex and Vertex a should not belong to AdditiveGroup If anyone knows how to walk through the whole module in monad Q that might bring more power to this library. I.e. walk through OpenGL.Raw and make declarations for all its scalar types. Thank you _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Nikolay Orlyuk 2012-05-20T09:59:47 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17245 <pre>I have returned from the shadows of the intenet to maintain some packages! Version 2.0.7 of protocol-buffers (3 packages) has been uploaded to hackage. This makes it compile with ghc-7.4.1 and handle missing package names better. Thanks to everyone who sent email and patches, including Nathan Howell, Alexey Khudyakov, Howard B. Golden, Bryan O'Sullivan, Michael Stone, Daniel Rebelo de Oliveira, Paul Graphov, Tsurann, Sergei Trofimovich, Yitzchak Gale. The usual hackage links: http://hackage.haskell.org/package/hprotoc http://hackage.haskell.org/package/protocol-buffers-descriptor http://hackage.haskell.org/package/protocol-buffers And the darcs repo is at: http://code.haskell.org/protocol-buffers/ Q: What is protocol-buffers? A: It is a Haskell version of Google's protocol buffer wire protocol, see http://code.google.com/p/protobuf/ for a full description. Q: What does the hprotoc executable do? A: It convers "protocol-buffer descriptor files" into Haskell code to implement those data messages. Q: What does the protocol-buffers library do? A: It is the runtime API for using the binary protocol, serializing and deserializing the data types generated by hprotoc. Q: What is the protocol-buffers-descriptor library do? A: It is the support library for parsing "protocol-buffer descriptor files" into data structures. Most of this code is generated by hprotoc from a "protocol-buffer descriptor file" for "protocol-buffer descriptor files". Yes, it had to be bootstrapped. </pre> Chris Kuklewicz 2012-05-19T15:51:53 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17238 <pre>Separate from whether or not we actually want this -- is it feasible? Here's my situation. When working on parallel programming libraries in Haskell there are very often unsafe operations one wants to do within an otherwise pure model. For example, Accelerate currently violates safe haskell because it trusts the user to provide an associative function to parallel "fold". No associativity, no referential transparency. The solution is to put fold in a separate namespace and mark that module as Unsafe. Likewise for certain monad-par operations that are unsafe. But this factoring can have a serious impact. Not only are extra modules required, but extra type classes as well. For example, if Accelerate is ever refactored for "Safe Haskell" then the following ParAccelerate type class probably should be as well: https://github.com/simonmar/monad-par/blob/5cc656bc45dc473d7a185ec99bb156192f54d520/abstract-par-accelerate/Control/Monad/Par/Accelerate.hs#L75 I.e. ParAccelerate &amp; ParAccelerateUnsafe for the "unsafeHybrid" operation. But this starts to be death by a thousand organizational factorings! - The package, abstract-par-accelerate, is already factored out from abstract-par just to avoid an unnecessary Accelerate dependency (which used to mean CUDA errors). (And *another* factoring is possibly warranted for whether or not the module depends on accelerate-io.) - The file would be separate to mark it as Safe Haskell. - The type class ParAccelerateUnsafe would be separate so as to put it in a separate file. What's a possible solution? If, in addition to "Safe" and "Unsafe" modules, there were "Partially Safe" modules, which exported a mix of safe and unsafe identifiers, then this could all be much cleaner. The simple rule is that any reference whatsoever to an unsafe identifier disqualifies the client code. For example, in the above ParAccelerate type class we would mark the unsafeHybrid binding with something like {-# UNSAFE unsafeHybrid #-}. We wouldn't even have to factor it out of the type class. Likewise, Accelerate could mark "fold" as unsafe (providing safe variants as well) without introducing module namespace bloat and confusion. What do you think? -Ryan _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Ryan Newton 2012-05-14T15:18:20 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17231 <pre>Folks, I am proposing to extend the xhtml package slightly to better support attribute munging. Currently you would use (!) to add a bunch of attributes to an element, thus: b1 = button noHtml ! [name "go", value "go"] The problem, as pointed out by mistuke[1] is that there is no way to safely add attributes as this could result in an attribute being bound ambiguously and illegally [2] thus: b2 = b1 ! [value "oops"] Apparently this can lead Haddock to generate illegal (X)HTML [1]. My proposed solution is to add a new CHANGEATTRS class with the overloaded function: changeAttrs :: CHANGEATTRS a =&gt; a -&gt; ([HtmlAttr] -&gt; [HtmlAttr]) -&gt; a and to export a function for analysing the (abstract) HtmlAttr type: htmlAttrPair :: HtmlAttr -&gt; (String, String) CHANGEATTRS/changeAttrs/htmlAttrPair works just like ADDATTRS/(!) except that the attributes can be analysed and transformed. extend_name :: Html -&gt; Html extend_name h = h `changeAttrs` map f where f a = case htmlAttrPair a of ("name",nm) -&gt; name $ "foo_" ++ nm _ -&gt; a Finally, I have an embarrassing confession to make -- I forgot that I should be getting the changes reviewed here -- even for such a modest widening of the API -- and have already put out 3000.2.1 with these additions onto Hackage! Comments and feedback welcome though, Chris [1] https://github.com/haskell/xhtml/issues/2 [2] http://www.w3.org/WAI/GL/WCAG20-TECHS/H94.html _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Chris Dornan 2012-05-11T20:49:53 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17230 <pre>Dear list, I have written a package, reactive-banana-wx, which seems to be quite enticing to Haskell beginners. It's an implementation of the fabled functional reactive programming (FRP), so it's natural that people want to play around with it to see what it is all about. I imagine that the latest parallelism packages also serve a similar audience. Of course, to play around with a package, you have to be able to install it, hopefully painlessly. As the maintainer, I have adopted the following principles as they appeared sound to me: 1. My package installs and works without any hitch on the latest Haskell Platform. This is easier said than done, because one of my dependencies is wxHaskell, which tends to have hitches at times. Occasionally, I restrict the version number to a specific, older wxHaskell version that I know to be bug free. In other words, the idea is that a complete Haskell beginner will be able to install my package with the standard setup even if he knows nothing about the Haskell ecosystem. 2. If the user has a setup that doesn't fit the dependencies I prescribe, then I expect him to change the version constraints himself (and hopefully tell me whether it works.) The idea is that having a non-standard setup is an indication that the user is no longer a beginner, so I can expect him/her to know how to change version constraints. With these principles in mind, imagine my surprise, then, to discover that the "Haskell Platform" on Ubuntu 12.04 includes GHC 7.4.1 http://packages.ubuntu.com/precise/haskell-platform Clearly, this must be a fake Haskell Platform, because the latest real Haskell Platform is still at GHC 7.0.4 at the time of this writing. Unfortunately, my principle 1 is now rendered moot. I don't quite know what to do. I understand that there is a need to get the latest GHC into the standard setup, but creating a "fake" Haskell Platform seems like a mistake to me, as it contradicts the use case "complete Haskell beginner" I described above. Not to mention that I'm stuck with the "real" Haskell Platform on Mac OS X and would have to manage separate cabal installations if I want to thoroughly test my package for all compiler versions. Or is it my principles that need to change? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com </pre> Heinrich Apfelmus 2012-05-11T08:23:21 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17229 <pre>--- GHC/Exts.hs | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/GHC/Exts.hs b/GHC/Exts.hs index 0bf8f7f..8281895 100755 --- a/GHC/Exts.hs +++ b/GHC/Exts.hs &lt; at &gt;&lt; at &gt; -102,7 +102,7 &lt; at &gt;&lt; at &gt; sortWith :: Ord b =&gt; (a -&gt; b) -&gt; [a] -&gt; [a] sortWith f = sortBy (\x y -&gt; compare (f x) (f y)) -- | The 'groupWith' function uses the user supplied function which --- projects an element out of every list element in order to to first sort the +-- projects an element out of every list element in order to first sort the -- input list and then to form groups by equality on these projected elements {-# INLINE groupWith #-} groupWith :: Ord b =&gt; (a -&gt; b) -&gt; [a] -&gt; [[a]] </pre> Simon Hengel 2012-05-10T08:44:36 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17227 <pre>Would it be possible to relax the upper bound on parallel's dependency on containers to permit the use of 0.5? I was able to adjust about 20-30 of my packages to support the new containers with no change, right up until I ran into packages that use or transitively use parallel, and now I'm stuck. -Edward _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Edward Kmett 2012-05-09T00:12:13 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17219 <pre>Hi, I've recently noticed unGetChan and isEmptyChan have been deprecated as a result of these two bug reports: http://hackage.haskell.org/trac/ghc/ticket/3527 http://hackage.haskell.org/trac/ghc/ticket/4154 I was working on an alternative implementation of concurrent channels (concurrent streams) to use as a building block for FRP and thought while I'm at it I'd have a go at fixing the problem with concurrent channels. I've attached the files for a reimplementation of concurrent channels, 2 implementations of lower-level concurrent queues, one that only supports non-blocking reads, and another that supports both blocking and non-blocking reads, and an implementation of concurrent streams. The reimplementation of concurrent channels is built on top of the blocking queue. The streams are built on top of the non-blocking queue and have Functor and Applicative instances. The reimplementation of concurrent channels passes the two tests in the bug reports above. I haven't run further tests though. The logic for how the channel operations are supposed to proceed is summarized in Chan.hs. Due to an extra lock this implementation is likely a bit slower than the old implementation. One assumption that has been made is that IORef reads and writes are atomic. In other words that if there are two or more concurrent writes to the same IORef, one of them will successfully write its data to it. I have not been able to find exact semantics of IORefs though I've asked in #haskell and others have suggested that the assumption is valid. Proposal: 1) split concurrent channels from base into a separate library of higher level concurrency primitives 2) add concurrent queues to the library of higher level concurrency primitives 3) replace concurrent channels with the new implementation based on concurrent queues 4) add concurrent streams to the library of higher level concurrency primitives I was in a bit of a rush to write this up and post the code after finding out that the new Haskell platform will be released this month though it seems unlikely this would go in at this point - probably for the best as the code hasn't been tested much. I'm also not sure if concurrent streams would be more appropriate on Hackage? Thoughts and comments appreciated. Deadline: 8th of June. Ivan _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Ivan Tomac 2012-05-07T15:25:35 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17218 <pre>Hi again, this weekend there was (among other things) another release of hecc, the Elliptic Curve Cryptography Library for Haskell, to be found at http://hackage.haskell.org/package/hecc (or simply by "cabal install hecc") This release of hecc uses a new library (hF2), which abstracts the whole F(2^e). Please refer to that library for more information. With this release, the whole functionality of hecc should be usable again and the F2-using functions should be a bit faster now (but: not fast per se, especially if compared against other implementations). Feel free to play around with it and try to make it faster, I plan to do the same. ;-) As always: It is in development and may change, expect only crypto-api instances to be somewhat stable (someday). A fresh start into the new week, Marcel </pre> Marcel Fourné 2012-05-07T08:18:43 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17217 <pre>Hi, this is the first release of hF2, a new F(2^e) backend for cryptographic code, to be found at http://hackage.haskell.org/package/hF2 (or simply by "cabal install hF2") This library is intended to be portable, somewhat timing-attack resilient and it's interface is geared toward the use in the "hecc" library (others may follow). Right now it uses unboxed Bit-Vectors (see: "bitvec") and with this the "vector" library, which seems to be the focus of optimization in array-like datastructures. The datatype "F2" is intended to hide the implementation from it's users, so repa/DPH or other implementations may provide parallelization for the arrays - they are just so obviously parallel, but the first prototype with this was painstakingly slow (...yes, that was my fault). Have fun with this, I sure did! Marcel </pre> Marcel Fourné 2012-05-07T08:29:07 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17189 <pre>Hello all, I recently (re)noticed the following duplication: base:Control.Applicative newtype Const a b = Const { getConst :: a } instance Functor (Const m) where... instance Monoid m =&gt; Applicative (Const m) where... transformers:Data.Functor.Constant newtype Constant a b = Constant { getConstant :: a } instance Functor (Constant a) where... instance Foldable (Constant a) where... instance Traversable (Constant a) where... instance (Monoid a) =&gt; Applicative (Constant a) where... I don't see any reason for this redundancy. I propose we: (1) add the Foldable and Traversable instances to base, and (2) deprecate transformers:Data.Functor.Constant This will cause breakage to any orphan instances of Foldable/Traversable for Const, but that seems fine by me. Eventually we'll want to remove transformers:Data.Functor.Constant (or have it re-export the Const stuff from base:Control.Applicative); but that can be handled later. Deadline: 14 May 2012. </pre> wren ng thornton 2012-04-30T05:33:39 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17180 <pre>Hi all, Currently Data.Map has a Monoid instance, but it's rather lossy and not as general as it could be: instance (Ord k) =&gt; Monoid (Map k v) where mempty = empty mappend = union mconcat = unions The instance would be much nicer if it required a Monoid on v and used unionWith mappend instead of just union. The current behavior could be emulated by using First/Last as the Monoid (or ideally a semigroup, but that's or another discussion), but other more interesting Monoid instances could also be used for the values. I realize that changing instances could break code, but I'd be curious to see how many people even use the current monoid instance. Does anyone have any system for testing hypotheses like this (by typechecking a large randomized chunk of hackage or something)? It looks like the idea has been around for at least five years: http://hackage.haskell.org/trac/ghc/ticket/1460 but the proposal was abandoned, so I wanted to see if I could get people to start talking about it again. Thanks, Dan _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Daniel Peebles 2012-04-28T01:04:10 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17175 <pre>Hi, trying to install haskeline together with other packages using cabal-install-0.14.0 resulted in a failure due to a too restrictive constraint. &gt; cabal install mtl haskeline --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): haskeline-0.4 # because mtl-2.1.1 is already installed This installation of haskeline-0.4 fails! &gt; cabal install transformers haskeline --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): mtl-1.1.1.1 haskeline-0.6.4.6 # transformers-0.3.0.0 is already installed &gt; cabal install haskeline --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): transformers-0.2.2.0 mtl-2.0.1.0 haskeline-0.6.4.6 Cheers Christian </pre> Christian Maeder 2012-04-27T13:23:34 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17170 <pre>Hi all, this came up when discussing increasing size of GHC binary. Currently all folds in containers package are marked as INLINE. This has following effects: 1) the code using folds can be (much) more efficient -- for example, when calling statically known function. If the unfolding of that function is available, GHC can spot strictness and unbox values -- so `foldl (+) (0::Int)` evaluated the sum strictly and without allocating space for intermediate Ints. 2) the resulting binary size increases. If the folds in containers package are not INLINEd, the stripped GHC binary shrinks by 303kB, which is 0.8% of its size. Therefore we have speed vs. code size trade-off. FYI, Prelude.foldr is always inlined, Prelude.foldl is inlined only when GHC thinks it is worth it. Simon Marlow suggested that folds could be marked INLINABLE. Then they would probably not be inlined automatically, but one could say inline foldr to inline the fold on the call sites she chooses. Personally I am a bit in favor of keeping the folds INLINE. That allows the users of containers to get best performance without any change to the code (i.e., adding explicit `inline`). The price to pay is code size increase, which I consider minor (0.8% for GHC binary). Any other thoughts? Cheers, Milan </pre> Milan Straka 2012-04-26T11:10:24 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17160 <pre>Hi, I was trying to install ad (Automatic Differentiation) but got the following error. I guess the answer is to upgrade my ghc (perhaps someone could confirm) but I am using the Haskell Platform and would rather stick with that. I see from http://hackage.haskell.org/platform/ that the next release is due out in May. Will that be early May? in which case I may well wait a week or will it be late May? in which case I might bite the bullet and upgrade my ghc. Thanks, Dominic Building template-haskell-2.7.0.0... [1 of 7] Compiling Language.Haskell.TH.Syntax.Internals ( Language/Haskell/TH/Syntax/Internals.hs, dist/build/Language/Haskell/TH/Syntax/Internals.o ) [2 of 7] Compiling Language.Haskell.TH.Syntax ( Language/Haskell/TH/Syntax.hs, dist/build/Language/Haskell/TH/Syntax.o ) [3 of 7] Compiling Language.Haskell.TH.PprLib ( Language/Haskell/TH/PprLib.hs, dist/build/Language/Haskell/TH/PprLib.o ) Language/Haskell/TH/PprLib.hs:55:10: Illegal instance declaration for `Show Doc' (All instance types must be of the form (T t1 ... tn) where T is not a synonym. Use -XTypeSynonymInstances if you want to disable this.) In the instance declaration for `Show Doc' Updating documentation index /Users/Test/Library/Haskell/doc/index.html cabal: Error: some packages failed to install: ad-1.3.0.1 depends on template-haskell-2.7.0.0 which failed to install. template-haskell-2.7.0.0 failed during the building phase. The exception was: ExitFailure 1 The Glorious Glasgow Haskell Compilation System, version 7.0.3 </pre> Dominic Steinitz 2012-04-21T15:13:41 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17155 <pre>Hello, I'm pretty new to Haskell and I hope this list is the appropriate place to ask the following question: When I use cabal to install a libary or a program, are there any integrity checks done? Preferably, are there digital signatures checked? So far I couldn't find anything related to integrity checking in cabal -- but I found it a bit hard to believe that there is no such mechanism at all. If there is none, are there any plans on adding such a mechanism? For instance, one could configure cabal to complain whenever a package's signature could not be checked and implement some light-weigth signature checking via pgp-keys. Thanks, m. </pre> M. Schulte 2012-04-20T13:04:14 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17154 <pre>I went to Aleksandar Prokopec's talk about Concurrent Tries at the Scala day earlier this week. I thought it was pretty cool. Here's the paper. http://infoscience.epfl.ch/record/166908/files/ctries-techreport.pdf http://lampwww.epfl.ch/~prokopec/ctries-snapshot.pdf Maybe we should have a Haskell version? Maybe we already do? Simon _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Simon Peyton-Jones 2012-04-20T09:47:04 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17146 <pre>Ever find yourself wanting to generate a tuple of random things? Instances are trivial to write in Haskell 98: instance (Random a, Random b) =&gt; Random (a, b) where randomR ((loL, loR), (hiL, hiR)) g = ((l, r), g'') where (l, g') = randomR (loL, hiL) g (r, g'') = randomR (loR, hiR) g' random g = ((l, r), g'') where (l, g') = random g (r, g'') = random g' Can we add instances like this to System.Random in the random package? </pre> Dan Burton 2012-04-17T02:04:52 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17142 <pre>Hey, Currently it seems that cabal-install lacks IO concurrency in its various operations (i.e: download packages concurrently to their compilation). Specifically, I found it to be a major bottleneck during "cabal update" operations. The download, decompression, and use of the decompressed index are all serially executed, and all take quite a bit of time, and could probably be executed in parallel easily. To make "cabal update" execute the download and decompression concurrently, it would be nice to use a streaming decompressor on a stream download. The approach I had in mind was replacing the use Network.HTTP and zlib with use of the conduits counterparts. Additionally, use of conduits can probably ease addition of status reports (X% completed) by injecting progress reporters in the conduit pipeline. "cabal update" progress could be less opaque that way. My question is: Would patches that add conduit use and demonstrate performance benefits be welcome? I don't want to embark on this adventure if there's a good reason to avoid it in the first place. Eyal _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Eyal Lotem 2012-04-14T23:43:23 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17136 <pre> Some packages that I use import mtl, but latest mtl requires transformers-0.2. It seems that simply the constraint must be relaxed. Btw. can the maintainers of mtl and transformers please specify the repositories for these packages in the Cabal description? </pre> Henning Thielemann 2012-04-07T18:35:45 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/17135 <pre>Hi again, this is the third release of hecc, the Elliptic Curve Cryptography Library for Haskell, to be found at http://hackage.haskell.org/package/hecc (or simply by "cabal install hecc") The changes since hecc-0.2 have been numerous, from simple fixes of a standard curve definition (NIST p521), to addition of the sometimes requested NIST p384, to addition of a wholly new F(2^e)-backend (only prime curves can get boring). Also: small stuff I can't remember that well. The new F(2^e)-backend is broken for some functions, has hackish datastructures and horrible performance, but should give an outlook into some parallelism achievable once it is fixed. It was also the basis for further work, which will eventually land here. REMEMBER: This is very much ALPHA-stadium work, please test it yourself and don't do bad stuff to me if things fail or change in the future due to my fixing the worst parts. ;-) I haven't forgotten the crypto-api, but my life has been turbulent and my thesis took quite some time (plus: randomness extractors and other stuff needed), so please bear with me or send further patches like the good ones that came in already. A happy long weekend to you (dance if it suits you), Marcel </pre> Marcel Fourné 2012-04-06T11:43:04 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.libraries