- Haskell-Cafe - Haskell.org

ANN: stm-chans: Additional types of channels for STM.
by wren ng thornton 04 Apr '11

04 Apr '11

-------------------------------------------- -- stm-chans 1.0.0 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.TChan but with additional features. In particular it offers these types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. This is like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. This combines the capabilities of TBChan and TMChan. In addition, the stm-chans package offers a (partial) compatibility layer for some API improvements still making their way into the stm package[1]. These new functions include: * tryReadTChan :: TChan a -> STM (Maybe a) A version of readTChan which does not retry. Instead it returns Nothing if no value is available. * peekTChan :: TChan a -> STM a Get the next value from the TChan without removing it, retrying if the channel is empty. * tryPeekTChan :: TChan a -> STM (Maybe a) A version of peekTChan which does not retry. Instead it returns Nothing if no value is available. [1] http://article.gmane.org/gmane.comp.lang.haskell.libraries/15507 -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren

3 3

Ann: contstuff, dnscache, ihttp, ismtp, netlines, yesod-tableview
by Ertugrul Soeylemez 04 Apr '11

04 Apr '11

Hello fellow Haskellers, (once again posted to the cafe, because the Haskell mailing list rejects my mails.) I have released quite a few libraries over time on Hackage. I feel they are stable enough now to announce them here. * contstuff: Fast and flexible monad transformers based on the CPS concept. Mainly it helps getting rid of large transformer stacks, because it unifies some monad transformers (like StateT and ContT), and it is also faster than the naive approach. This library is comparable to a combination of the transformers package with Edward Kmett's monad-ran package, but without hiding the CPS transformation. In early benchmarks ChoiceT turned out to be twice as fast as normal Haskell lists, and it is also a proper list monad transformer. Finally in the Control.ContStuff.Classes module you find lots of useful utility classes, which seem to be unique to contstuff. * dnscache: Handy DNS caching library. This library automatically manages a set of resolver threads for you, which share a reply cache. This allows very fast mass-resolution. The library also comes with a handy command line utility called 'massdns' for quick resolution of even very large lists of entities. Call massdns without arguments to get usage help. * ihttp: This is an HTTP library based on enumerators giving you maximum flexibility and control over the connection. Using proper iteratees you can simply implement e.g. proxy clients (my main use case), but also HTTP servers. Using proper enumeratees you can also encapsulate the connection in an SSL/TLS layer, but unfortunately there doesn't seem to be such an SSL/TLS implementation yet. * ismtp: This is an advanced ESMTP library, which allows you to structure your sessions as you like. It also features an automated resolver for MX records using the dnscache library. Right now there is support for most of the base functionalities of the protocol as specified in RFC 821 (SMTP) and RFC 1425 (service extensions). An update to RFC 2821 is planned, but is not necessary for practical purposes. The new RFC mainly removes some unneeded features and unifies the two mentioned RFCs. Right now there is no support for SMTL (SASL) authentication, but it is planned for a near future release. For the time being you can implement your own iteratees for this purpose, if you depend on authentication. * netlines: This is a library for writing implementations of text-based protocols. In particular it allows reading lines safely from untrusted sources with a maximum length in constant space. * yesod-tableview: For web applications using Michael Snoyman's Yesod web framework this library implements an easy to use table renderer mainly for database records. It is in an early stage of development right now, but as the need arises, I will extend it. To use the networking libraries, you should be familiar with John Millikin's 'enumerator' package. If you're not, I recommend studying it, because it is a useful library for all kinds of stream processing like network connections, files and concurrent channels. All mentioned libraries have been tested extensively for correctness and safety. Especially the networking libraries have undergone a lot of penetration testing. However, I'm only one developer, so I would be glad to hear about any vulnerabilities and other shortcomings you find. Usually I have a very short response time to bugs in these libraries, so please don't hesitate to contact me. Feature requests are also welcome, of course. =) Please note that major version numbers specify interface versions in my libraries. In other words, a new major version of a package usually means that the API has changed in a way, which is likely to break dependent packages. I would like to use this opportunity to thank a few people in particular (alphabetically): - Cale Gibbard, - Edward Kmett, - John Millikin, - Bryan O'Sullivan and - Michael Snoyman. I appreciate your efforts both in libraries and support. Many thanks, guys! Thanks also to the rest of the innovative and helpful Haskell community. Greets, Ertugrul -- Key-ID: E5DD8D11 "Ertugrul Soeylemez <es(a)ertes.de>" FPrint: 0F12 0912 DFC8 2FC5 E2B8 A23E 6BAC 998E CE40 2012 Keysrv: hkp://subkeys.pgp.net/ -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

2 1

ANNOUNCE: FreeType 2 Bindings
by Jason Dagit 04 Apr '11

04 Apr '11

I'm excited to announce the immediate availability of FreeType 2 bindings on hackage. These bindings are based off the 2.4.4 release of FreeType 2 and use the BSD licensing option for FreeType 2. This package should be of interest to OpenGL users as it provides a way to get nice looking fonts into your OpenGL programs. This binding is still in its infancy, hence version 0.0.1, but enough of the API is exposed that I was able to convert the example1.c program in the FreeType tutorial to Haskell. Here are a few relevant links: * What is FreeType: http://www.freetype.org/freetype2/index.html * Example program and tutorial: * http://www.freetype.org/freetype2/docs/tutorial/step1.html * http://www.freetype.org/freetype2/docs/tutorial/example1.c * Haskell version of tutorial: * https://github.com/dagit/freetype2/blob/cabalization/Main.hs * Example program output (yes, their tutorial example really does draw the bitmap as a grid of text, scroll around to find the word "blah"), more interesting examples to come later: * http://hpaste.org/45239/aoeu The current API level is "raw" and makes no attempts to present a good Haskell-like interface to the library. My plan is to build a higher level interface on top once a sufficient portion of the API is available to Haskell. You can find the source on github in the cabalization branch: * https://github.com/dagit/freetype2 Patches welcome! Thanks, Jason

2 2

llvm package on Windows
by Jacques Carette 04 Apr '11

04 Apr '11

I am trying to install llvm-0.9.0.1 on Windows (through cygwin), on top of a clean install of Haskell Platform 2010.2.0.0. I do cabal install llvm --configure-option --with-llvm-prefix="C:\\llvm" (which is where I unpacked llvm-gcc4.2-2.8-x86-mingw43.tar.bz2). This fails with .....mingw\bin\ld.exe: cannot find -lLLVMXCoreAsmPrinter (which is indeed the first -l option on the gcc line). [I also tried the llvm-ht package, same issue; I can't tell which of the 2 packages is 'best' from the online doc] Perhaps I need to 'install' llvm more thoroughly? [Most of the instructions online seem to assume you want to use llvm-gcc, which is not my case] Any clues? Jacques

2 1

Improvements to crypto-API: CTR CMAC and SIV modes
by klondike 04 Apr '11

04 Apr '11

Hi, The attached files provide some preliminary support for the CTR, CMAC and SIV modes of operation on the crypto-api for both strict and lazy bytestrings. My main worries here are that the implementations may be vulnerable to timing attacks, and that the code in CPolys may be subject to copyright restrictions since it may be a derivative work from "Table of Low-Weight Binary Irreducible Polynomials" by Gadiel Seroussi (since all I did was apply transformations to the original PDF to get the data). As a side note, if I have time I'll improve the dbl and shift operations so they can work directly over the bytestrings which may be faster than converting and back. I'll also try both parallelizing the implementation of the counter mode and make it work with transformations other than adding one.

1 0

Haskell programs as specifications
by Patrick Browne 03 Apr '11

03 Apr '11

Hi, Attached are two programs that represent one-way and two-way traffic on a road. I can get the programs to produce reasonable results that match our intuitive ideas of roads. However, I have 2 question about the programs: 1)I cannot get the result suggested by the author that t1 should give true in prog1 and false in prog2. 2)My second question is more theoretical. It is stated by the author that type checking and excitability provide verification. In this case verification probably means checking that an instance is consistent with its type class. Does verification using these techniques in Haskell have any firmer logical foundation than say doing the verification in Java? I am aware that Haskell uses inference for type checking, but is the net result superior to compilers that do not use inference? Also, is Haskell execution based purely on logic? Regards, Pat This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie

3 4

fundeps => type family
by Tad Doxsee 03 Apr '11

03 Apr '11

Hi All, Last week I asked a question with the subject "object oriented technique". I got a lot very helpful answers and I thank all who contributed. At the end of my question, I alluded to some problems that I was having with what I wanted to do next, which was to add additional polymorphism. I figured out a solution, which is: ------------------------------------------------- {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} data Rectangle a = MkRectangle { rx, ry, rw, rh :: a } deriving (Eq, Show) drawRect :: Show a => Rectangle a -> String drawRect r = "Rect (" ++ show (rx r) ++ ", " ++ show (ry r) ++ ") -- " ++ show (rw r) ++ " x " ++ show (rh r) data Circle a = MkCircle {cx, cy, cr :: a} deriving (Eq, Show) drawCirc :: Show a => Circle a -> String drawCirc c = "Circ (" ++ show (cx c) ++ ", " ++ show (cy c)++ ") -- " ++ show (cr c) r1 = MkRectangle 0 0 3 2 r2 = MkRectangle 1 1 4 5 c1 = MkCircle 0 0 5 c2 = MkCircle 2 0 7 class ShapeC a s | s -> a where draw :: s -> String copyTo :: s -> a -> a -> s {- -- GADT version data ShapeD a where MkShapeD :: ShapeC a s => s -> ShapeD a -} -- Existential Quantification version data ShapeD a = forall s . ShapeC a s => MkShapeD s instance ShapeC a (ShapeD a) where draw (MkShapeD s) = draw s copyTo (MkShapeD s) x y = MkShapeD (copyTo s x y) mkShape :: ShapeC a s => s -> ShapeD a mkShape s = MkShapeD s instance Show a => ShapeC a (Rectangle a) where draw = drawRect copyTo (MkRectangle _ _ rw rh) x y = MkRectangle x y rw rh instance Show a => ShapeC a (Circle a) where draw = drawCirc copyTo (MkCircle _ _ r) x y = MkCircle x y r r1s = MkShapeD r1 r2s = MkShapeD r2 c1s = MkShapeD c1 c2s = MkShapeD c2 shapes1 = [r1s, r2s, c1s, c2s] drawing1 = map draw shapes1 shapes2 = map mkShape rs ++ map mkShape cs drawing2 = map draw shapes2 -- copy the shapes to the origin then draw them shapes3 = map (\s -> copyTo s 0 0) shapes2 drawing3 = map draw shapes3 ------------------------------------------------- The main difference with my previous version is that the above is polymorphic in the type for the origin and dimensions. (I used a Double previously.) Also, the above version uses existential quantification instead of GADTs, only because some said that that method is more "standard". I had to use functional dependencies in the defintion of class ShapeC to get it to compile and run. Ed Yang's excellent post (http://blog.ezyang.com/2011/03/type-tech-tree) says that type families are equivalent to multiparameter type classes + functional dependencies, so I tried to rewrite the above using type families, but I got stuck. Also the GHC documentaton (http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/type-families.h…) says that "Equality constraints ... enable a simple translation of programs using functional dependencies into programs using family synonyms instead. So I tried: class (T s ~ a) => ShapeC a s where type T s :: * draw :: s -> String copyTo :: s -> T s -> T s -> s but got a compile error: Alas, GHC 7.0 still cannot handle equality superclasses: T s ~ a So my question is, how does one convert the above code to use type families instead of functional dependencies? Is one technique preferable over another? Thanks, Tad

2 2

[ANNOUNCE] Data-flow based graph algorithms
by Mitar 03 Apr '11

03 Apr '11

Hi! Based on my Etage data-flow framework: http://hackage.haskell.org/package/Etage I have made a package to show how to implement graph algorithms on top of it: http://hackage.haskell.org/package/Etage-Graph I invite everybody to take a look and see how it is possible to implement known control-flow algorithms in a data-flow manner. For now, only shortest paths search is implemented (from all to all nodes). The nice feature is that such approach is easily parallelized. It quite heavily uses Haskell threads so it is also useful to benchmark and test them, especially for graphs with many nodes (> 300). There is documentation, but because of this bug it is not visible: http://hackage.haskell.org/trac/hackage/ticket/656 Mitar

1 0

Unboxing CFloat and GLfloat
by Jason Dagit 03 Apr '11

03 Apr '11

First a bit of background. Sometimes I would like to be able to create unboxed arrays of CFloats and GLfloats. Both of these are defined as newtypes around types that can be unboxed (e.g., Float). I'm assuming GHC here. As far as I can tell, the newtyping is there to help programmers pick a representation that matches the C compiler's representation on their platform without having to use CPP in their Haskell code. Would it be possible to add instances like these? instance MArray (STUArray s) GLfloat (ST s) instance MArray IOUArray GLfloat IO instance MArray (STUArray s) CFloat (ST s) instance MArray IOUArray CFloat IO I would also want instances for the other C types that map to Haskell types that are unboxed and the other GL types too. For example, in my program I imported all the right libraries and added this instance as an experiment: instance MArray (STUArray s) GLfloat (ST s) where {-# INLINE getBounds #-} getBounds (STUArray l u _ _) = return (l,u) {-# INLINE getNumElements #-} getNumElements (STUArray _ _ n _) = return n {-# INLINE unsafeNewArray_ #-} unsafeNewArray_ (l,u) = unsafeNewArraySTUArray_ (l,u) fLOAT_SCALE {-# INLINE newArray_ #-} newArray_ arrBounds = newArray arrBounds 0 {-# INLINE unsafeRead #-} unsafeRead (STUArray _ _ _ marr#) (I# i#) = ST $ \s1# -> case readFloatArray# marr# i# s1# of { (# s2#, e# #) -> (# s2#, unsafeCoerce (F# e#) #) } {-# INLINE unsafeWrite #-} unsafeWrite (STUArray _ _ _ marr#) (I# i#) e = ST $ \s1# -> let F# e# = unsafeCoerce e in case writeFloatArray# marr# i# e# s1# of { s2# -> (# s2#, () #) } I had to use an unsafeCoerce because the constructor for GLfloat is not exposed, and realToFrac has terrible performance because the following rules (suggested by Andy Gill) are missing from the OpenGL bindings: {-# RULES "realToFrac/a->GLfloat" realToFrac = \x -> GLfloat (realToFrac x) #-} {-# RULES "realToFrac/GLfloat->a" realToFrac = \(GLfloat x) -> realToFrac x #-} Even if I had those rules, I would still need to get access to the underlying representation (the e#) to have the right kind. GLfloat is defined in terms of CFloat which is defined in terms of other things. On my machine, CFloat happens to correspond to Float, although in general this need not be the case. So to do this instance correctly I would need to know, in general, what the underlying type is for CFloat. I think that means I would need to use the same macros as GHC, although I don't think that requires this instance to appear in base. I could just borrow the macros once I figure out the corresponding instance for CFloat. While the GLfloat instances don't need to be in base, the CFloat instance probably should be in base. Is this something I should make a library proposal for and submit patches? Is there an easier way to get these instances? Has someone already done this? Thanks, Jason

2 1

Call for contributions: Second edition of the Typeclassopedia
by Brent Yorgey 03 Apr '11

03 Apr '11

Hi all, It's time for a second edition of the Typeclassopedia [1], and I'd love to have your suggestions and contributions. You can send me suggestions and darcs patches [2] by email. For more detailed information, see my blog post [3]. -Brent [1] http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf [2] http://code.haskell.org/~byorgey/typeclassopedia/ [3] http://byorgey.wordpress.com/2011/04/03/call-for-contributions-second-editi…

1 0