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 (*^) f</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: W</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 "un</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 </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 Hask</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 f</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 handle</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, </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 i</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 ins</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 the</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: </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