- Haskell-Cafe - Haskell.org

File I/O benchmark help (conduit, io-streams and Handle)
by Michael Snoyman 09 Mar '13

09 Mar '13

Hi all, I'm turning to the community for some help understanding some benchmark results[1]. I was curious to see how the new io-streams would work with conduit, as it looks like a far saner low-level approach than Handles. In fact, the API is so simple that the entire wrapper is just a few lines of code[2]. I then added in some basic file copy benchmarks, comparing conduit+Handle (with ResourceT or bracket), conduit+io-streams, straight io-streams, and lazy I/O. All approaches fell into the same ballpark, with conduit+bracket and conduit+io-streams taking a slight lead. (I haven't analyzed that enough to know if it means anything, however.) Then I decided to pull up the NoHandle code I wrote a while ago for conduit. This code was written initially for Windows only, to work around the fact that System.IO.openFile does some file locking. To avoid using Handles, I wrote a simple FFI wrapper exposing open, read, and close system calls, ported it to POSIX, and hid it behind a Cabal flag. Out of curiosity, I decided to expose it and include it in the benchmark. The results are extreme. I've confirmed multiple times that the copy algorithm is in fact copying the file, so I don't think the test itself is cheating somehow. But I don't know how to explain the massive gap. I've run this on two different systems. The results you see linked are from my local machine. On an EC2 instance, the gap was a bit smaller, but the NoHandle code was still 75% faster than the others. My initial guess is that I'm not properly tying into the IO manager, but I wanted to see if the community had any thoughts. The relevant pieces of code are [3][4][5]. Michael [1] http://static.snoyman.com/streams.html [2] https://github.com/snoyberg/conduit/blob/streams/io-streams-conduit/Data/Co… [3] https://github.com/snoyberg/conduit/blob/streams/conduit/System/PosixFile.h… [4] https://github.com/snoyberg/conduit/blob/streams/conduit/Data/Conduit/Binar… [5] https://github.com/snoyberg/conduit/blob/streams/conduit/Data/Conduit/Binar…

5 12

Re: [Haskell-cafe] Shake, Shelly, & FilePath
by Greg Weber 09 Mar '13

09 Mar '13

Shelly is using system-filepath which was created as an improvement over using a simple String. For a build system in which you name all your files you may not care about the upside. If you want a version of Shelly that uses String you can try Shellish, its predecessor. Otherwise the shim should be written for Shake to use system-filepath. Greg Weber

1 0

ANNOUNCE: hF2-0.2
by Marcel Fourné 09 Mar '13

09 Mar '13

Hi, this is the second release of hF2, a 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 used in hecc for elliptic cryptography on binary field curves and came into existence during my master thesis. Since the code from back then some speedups and changes to data representation were made which lead to an increase in speed from the first correct protoype to this release by the factor 10^86 on my main development machine. Sadly, this is still slower than pure C or Assembler versions, but a lot more portable, (arguably) easier to read and easier to parallelize. The code does automatic bit slicing and uses mainly the vector library as a fast backend. Feats of this release: - Speed (256 bit curve point multiplication in hecc is now at about a second in time) - LINEAR speedup in threaded execution with the number of cores (up to the number of bits divided by the wordsize) - Manually tested - Prelude-like Interface (more in progress) - Mostly timing attack resistant (also in progress) Next up: Testing and fixing hecc for this release. Have a nice weekend, Marcel -- Marcel Fourné OpenPGP-Key-ID: 4991 8AA4 202F 12AC 41F7 6C77 CA83 BDF0 7454 5C72 I am a programmer. I want languages and libraries, not just huge tools.

1 0

ACCAT 2013: final call for participation and invitation to discussion
by Ulrike Golas 09 Mar '13

09 Mar '13

[Apologies if you receive more than one copy of the following announcement] FINAL CALL FOR PARTICIPATION AND INVITATION TO DISCUSSION ========== 8th International Workshop on Applied and Computational Category Theory ACCAT 2013 http://accat2013.zib.de/ Satellite Event of ETAPS 2013, Rome, March 17 2013 ========== Deadline for online registration: March 8 *Attendees are warmly invited to join the closing discussion. Please communicate your intention to deliver a position statement to the organizers.* ========== Since the 1960s, the use of category theory in computer science has been a fruitful one, ranging form automata theory to algebraic specification to programming languages. In recent years techniques and methods from CT have been adopted as a standard research tool, and considered as such in different venues around the world. The ACCAT workshop on "Applied and Computational Category Theory" has been one of these venues. Since its inception in 2006, ACCAT provided a forum where invited contributors presented their own research on different facets of category theory applied to computer science. Despite ACCAT success, we believe that the formula should be revised. Indeed, we have the feeling that a conference is missing where all kinds of applications of category theory to computer science can be presented (like the former CTCS conference, which somehow ended in 2006). This year, we would like to use the ACCAT forum to raise this issue and to discuss it within a larger audience. Thus, we invited 8 top researched in the area of application of category theory. The list of speakers are Samson Abramsky Robin B. Cockett Barbara Koenig Ugo Montanari Till Mossakowski Dusko Pavlovic Andrzej Tarlecki Glynn Winskel We do hope that the meeting will be fruitful, providing a good exchange of ideas and planting the seed for future events. Indeed, one of the outcome of the meeting is to decide whether to push an high-level workshop/conference on the application of category theory to computer science, or at least to verify the viability of a Daghstul meeting on the issue. Therefore, after the presentations, the workshop will end up with a general discussion among the attendees. -- Dr. Ulrike Golas Konrad-Zuse-Zentrum für Informationstechnik Berlin Takustr. 7, 14195 Berlin, Germany Tel. +49 30 84185 - 318 golas(a)zib.de -- www.zib.de/golas

1 0

Simple way to do something like ArrowChoice.right on a Conduit? (version 1.0.0)
by Joey Adams 09 Mar '13

09 Mar '13

Can I transform a conduit so some values are passed through unchanged, but others go through the conduit? For example: right :: Conduit i m o -> Conduit (Either x i) m (Either x o) This is named after the Control.Arrow combinator of the same name: right :: ArrowChoice a => a b c -> a (Either d b) (Either d c) Here's my use case (simplified): I want to compress data with zlib-conduit, which provides: compress :: Conduit (Flush ByteString) m (Flush ByteString) The Flush<http://hackage.haskell.org/packages/archive/conduit/latest/doc/html/Data-Co…>wrapper lets me flush the compressor so it will yield cached data right away (though hurting compression a little). But before compressing the data, I want to encode it, using this conduit: encode :: Conduit Entry m ByteString I want to combine these, so that if I send a 'Flush', it bypasses 'encode' and feeds to 'compress': compressEncode :: Conduit (Flush Entry) m (Flush ByteString) Thus, I need a variant of 'encode' that passes 'Flush' along: encode' :: Conduit (Flush Entry) m (Flush ByteString) In my actual program, I don't use Flush, so providing a Conduit combinator just for Flush would not help me. Is something like 'right' possible to implement with Conduit's public API? Here's an implementation using Data.Conduit.Internal (untested): import Control.Monad (liftM) import Data.Conduit.Internal (Pipe(..), ConduitM(..), Conduit) right :: Monad m => Conduit i m o -> Conduit (Either x i) m (Either x o) right = ConduitM . rightPipe . unConduitM rightPipe :: Monad m => Pipe i i o () m () -> Pipe (Either x i) (Either x i) (Either x o) () m () rightPipe p0 = case p0 of HaveOutput p c o -> HaveOutput (rightPipe p) c (Right o) NeedInput p c -> NeedInput p' (rightPipe . c) where p' (Left x) = HaveOutput (rightPipe p0) (return ()) (Left x) p' (Right i) = rightPipe $ p i Done r -> Done r PipeM mp -> PipeM $ liftM rightPipe mp Leftover p i -> Leftover (rightPipe p) (Right i) I'm wondering if we could have a Data.Conduit.Arrow module, which provides a newtype variant of Conduit that implements Arrow, ArrowChoice, etc.: import qualified Data.Conduit as C newtype Conduit m i o = Conduit (C.Conduit i m o) -- May need Monad constraints for these instance Category (Conduit m) instance Arrow (Conduit m) instance ArrowChoice (Conduit m) Does 'Conduit' follow Category, Monad, MonadTrans laws* these days? I'm not talking about Pipe in general, just the special case of it represented by the 'Conduit' type alias: Conduit i m o = ConduitM i o m () = Pipe i i o () m () Or are there some thorny issues (e.g. leftovers) that make following these laws impossible in some cases? Thanks for the input, -Joey * Assume functions that use Data.Conduit.Internal do so correctly.

2 8

Shake, Shelly, & FilePath
by Eli Frey 09 Mar '13

09 Mar '13

I began converting an unwieldy Makefile into a Haskell program via Shake, hoping that I could increase both its readability and modularity. The modularity has increased greatly, and I have found it exhilarating how much more I can express about my dependencies. However, readability has suffered. I quickly found that heavy shell interaction became unwieldy and I came out with code that was much more difficult to scan with my eyes then what I had in my Makefile. I attempted to fix this by using the Shelly library for my shell interactions, and was well pleased until I attempted to compile and discovered Shelly.FilePath is NOT Prelude.FilePath. Now I am left sprinkling coercions all over the place and am again shaking my head at how difficult to scan my code has become. I have been considering writing a shim over Shelly, but the prospect makes me uneasy. Has anyone else walked down this path before, and if so what did you bring away from the experience? I find this situation such a shame, as all my other experiences with both libraries have been quite wonderful. - Eli

2 1

ANNOUNCE: grid-4.0 (tile maps for board games or maths)
by Amy de Buitléir 08 Mar '13

08 Mar '13

I'm happy to announce a new major release of the grid package: http://hackage.haskell.org/package/grid https://github.com/mhwombat/grid/wiki (wiki) WHAT'S NEW: * The package now uses associated (type) synonyms instead of multi-parameter type classes with functional dependencies. * Added two new classes: FiniteGrid and BoundedGrid. Moved some functions from the Grid class to the other classes, as appropriate. For example, only finite grids need the "size" function, and only bounded grids need the "boundary" function. * Added Unbounded grids for square, hexagonal, and triangular tiles. * Updated the userguide to reflect the changes. ABOUT GRID: Grid provides tools for working with regular arrangements of tiles, such as might be used in a board game or self-organising map (SOM). Grid currently supports triangular, square, and hexagonal tiles, with various 2D and toroidal layouts. If you need a tile shape or layout that isn't currently provided, please let me know. See Math.Geometry.Grid for an example of how to use the package. Suggestions for improvement are welcome.

1 0

Parsing email id
by mukesh tiwari 08 Mar '13

08 Mar '13

Hello Everyone I am trying to learn parsec. I wrote this code to solve the problem ( http://www.spoj.com/problems/MAIN12C/ ) but getting time limit exceed so how can I improve this code ? In case of indentation, I have pasted the code at ideone ( http://ideone.com/AmxvZq ). import Data.List import qualified Text.Parsec.ByteString as PB import Text.Parsec.Prim import Text.Parsec.Char import Text.Parsec.Combinator import qualified Data.ByteString.Char8 as BS import Control.Applicative hiding ( ( <|> ) , many ) validChars :: PB.Parser Char validChars = alphaNum <|> oneOf "._" dontCare :: PB.Parser Char dontCare = oneOf "~!@#$%^&*()<>?,." {-- emailAddress :: PB.Parser String emailAddress = do _ <- many dontCare fi <- alphaNum se <- validChars th <- validChars fo <- validChars ft <- validChars restAddr <- many validChars let addr = fi : se : th : fo : ft : restAddr char '@' dom <- many1 alphaNum rest <- try ( string ".com" <|> string ".org" <|> string ".edu" ) <|> try ( string ".co.in" ) _ <- many dontCare return $ addr ++ ( '@': dom ++ rest ) --} emailAddress :: PB.Parser String emailAddress = conCatfun <$> ( many dontCare *> alphaNum ) <*> validChars <*> validChars <*> validChars <*> validChars <*> many alphaNum <*> ( char '@' *> many1 alphaNum ) <*> ( try ( string ".com" <|> string ".org" <|> string ".edu" ) <|> try ( string ".co.in" ) <* many dontCare ) where conCatfun a b c d e f dom rest = ( a : b : c : d : e : f ) ++ ( '@' : dom ++ rest ) collectEmail :: BS.ByteString -> String collectEmail email = case parse emailAddress "" email of Right addr -> addr Left err -> "" process :: ( Int , [ String ] ) -> BS.ByteString process ( k , xs ) = ( BS.pack "Case " ) `BS.append` ( BS.pack . show $ k ) `BS.append` ( BS.pack ": " ) `BS.append` ( BS.pack . show $ k ) `BS.append` ( BS.pack "\n" ) `BS.append` ( BS.pack ( unlines . filter ( not . null ) $ xs ) ) main = BS.interact $ BS.concat . map process . zip [ 1.. ] . map ( map collectEmail . BS.words ) . tail . BS.lines Regards Mukesh Tiwari

1 0

Country names and language names
by Obscaenvs 08 Mar '13

08 Mar '13

Hi! I am working on an app in Yesod that craves I18N. A problem I've come across there is giving correct country and language names based on currently selected language. So far, I've used the Yesod I18N message approach, but a lot of hand coding is involved. The iso3166-country-codes [1] package at Hackage by Jon Fairbairn provides a start in the right direction, but an obvious improvement upon it would be to have a function or map that takes an ISO 639 code and an ISO 3166 code and gives the correct human-readable name for the country as per the chosen target language (the ISO 639 code), and another function/map for languages. It would alleviate coding those pesky country and language switchers a *lot*, among other things. Jon Fairbarn that coded the iso3166-country-codes package said in private correspondence that it seemed worthwhile doing, but he couldn't do it in his spare time, which is understandable. I am willing to do some of the stuff involved (I know Swedish, French and some Turkish in addition to the ubiquitous English), but obviously it's too big a project for one man to handle (what with all the c'n'p involved :) ). I feel that this should be done, since it seems it isn't yet. I am inexperienced in coordinating such endeavours, though, so I would like to share that task at least to begin with, if possible. Any thoughts? [1] http://hackage.haskell.org/package/iso3166-country-codes-0.20111111.4 /Fredrik

4 6

[Announcement] New release of hArduino: Control your Arduino board from Haskell
by Levent Erkok 07 Mar '13

07 Mar '13

A new release (v0.5) of hArduno is out, now supporting servo-motors, shift-registers, seven-segment displays, and distance sensors. Comes with a bunch of examples to play around with: http://leventerkok.github.com/hArduino/ On Hackage: http://hackage.haskell.org/package/hArduino -Levent.

2 1