October 2014 - Haskell-Cafe

New mailing list: haskell-wai
by Michael Snoyman 07 Oct '14

07 Oct '14

After some discussion[1] on a Github issue, it became apparent that a number of people using WAI[2] could definitely benefit from having a shared discussion area. One obvious area of collaboration is discussing more efficient route dispatch algorithms, but there are likely many other topics worth discussing. Since none of the existing mailing lists seem appropriate for this, I've created a new mailing list: https://groups.google.com/d/forum/haskell-wai If you're using WAI- especially using it to write a web framework or coding applications directly against it, but even just indirectly via an existing framework- I'd highly recommend you join the discussion. [1] https://github.com/philopon/apiary-benchmark/pull/2 [2] http://hackage.haskell.org/package/wai

1 0

Re: [Haskell-cafe] Need help with scrap-your-boilerplate
by Roman Cheplyaka 06 Oct '14

06 Oct '14

On 06/10/14 21:24, Michael Sperber wrote: > Would using a different generic-programming framework help me do this > without the unsafe stuff? Yes. For example, using my traverse-with-class library: {-# LANGUAGE TemplateHaskell, MultiParamTypeClasses, FlexibleInstances, ConstraintKinds, UndecidableInstances, ImplicitParams, OverlappingInstances #-} import Data.Generics.Traversable import Data.Generics.Traversable.TH import Data.Proxy data Foo a = Foo a deriveGTraversable ''Foo -- define a class around our generic operation class Bar b where bar :: b -> b -- default case instance Bar a where bar x = x -- Foo-specific case instance Bar (Foo a) where bar x = x -- deep traversal recursiveBar :: (Bar a, GTraversable (Rec Bar) a) => a -> a recursiveBar x = let ?c = Proxy :: Proxy Bar -- traversal with the Bar dictionary in everywhere bar x Roman

1 0

New Functional Programming Job Opportunities
by Functional Jobs 06 Oct '14

06 Oct '14

Here are some functional programming job opportunities that were posted recently: Full Stack Functional Web Engineer at Front Row Education http://functionaljobs.com/jobs/8745-full-stack-functional-web-engineer-at-f… Senior Software Engineer at McGraw-Hill Education http://functionaljobs.com/jobs/8744-senior-software-engineer-at-mcgraw-hill… Cheers, Sean Murphy FunctionalJobs.com

1 0

Cryptographically secure random numbers?
by Bardur Arantsson 06 Oct '14

06 Oct '14

Hi all, I'm in a situation where I have to generate cryptographically secure random UUIDs, i.e. ones that cannot feasibly be guessed/predicted. Does anyone know what options there are in this space? Ideally, I'd like to fulfill as many of these points as possible: - Few big/complicated dependencies. - Avoid native C if possible (ditto for non-base dependencies). - Avoid RDRAND if possible. - Non-opaque UUID type. - Cross-platform if possible, but the main platform would be Linux. (Generating a UUID from a random stream would be trivial, so obviously a library for secure random numbers would be a-okay too.) Any suggestions?

3 3

Wreq: use basic auth and also change the response timeout
by Carlo Hamalainen 06 Oct '14

06 Oct '14

Hi, I am using Wreq with basic authentication. I also want to change the response timeout. The following code compiles but the user authentication fails: import Network.HTTP.Client (defaultManagerSettings, managerResponseTimeout) opts = defaults & manager .~ Left (defaultManagerSettings { managerResponseTimeout = Just 3000000000 } ) & auth .~ basicAuth "user" "pass" Perhaps I'm not using the lens onto the manager correctly? If I use just opts = defaults & auth .~ basicAuth "user" "pass" then my program runs fine. But I need the longer timeout for some large downloads. Thanks, -- Carlo Hamalainen http://carlo-hamalainen.net

1 1

ANN: Aivika 1.4 - simulation library
by David Sorokin 05 Oct '14

05 Oct '14

Hi Cafe, I'm glad to announce version 1.4 of my simulation library Aivika. The main improvement is that the main package aivika[1] contains a new module now, which is destined for simplifying an export of simulation results. Also the module can print in a text form the results of simulation. It recognizes queues, servers, arrival timers as well as references, variables and ordinary simulation variables. All this can help you to work on the simulation model directly from terminal if you like it, although, as before, my library provides powerful charting components that can automatically plot charts, save the CSV files, gather statistics, build histograms and unite them all in a single HTML file that can be then observed in your favorite Internet browser. I believe that all this must simplify much the process of modeling, simulation and analysis. At least, the deviation charts (using the rule of 3 sigma) cannot be underestimated as a tool of sensitivity analysis for the Monte-Carlo simulation. Another improvement is that the main package aivika can be compiled to JavaScript with help of Haste. I didn't check yet how it works in the browser but the package itself can be installed with help of haste-inst. I think this is a very interesting direction as it allows creating online flight simulators using Aivika. I hope you will find this information helpful. Best regards, David Sorokin [1] http://hackage.haskell.org/package/aivika

1 0

Unable to build a mingw cross compiler.
by Sven Bartscher 05 Oct '14

05 Oct '14

Greetings, I'm trying to build GHC to cross compile to windows. GCC and friends are in /usr/bin/x86_64-w64-mingw32-*, libraries and headers are in /usr/x86_64-w64-mingw32/{include,lib}. I configured with: ./configure --target=x86_64-w64-mingw32 \ --with-gcc=/usr/bin/x86_64-w64-mingw32-gcc # Needed because # otherwise /usr/bin/gcc # would be used Building fails with the following error: utils/hsc2hs/dist/build/Main.o: In function `s2nI_info': (.text+0x5c5): undefined reference to `GetModuleFileNameW' collect2: error: ld returned 1 exit status (The GHC invocation line is included in the attached file) So it seems that GHC either uses the wrong linker or invokes it with the wrong search path. However, the configure script detects the right linker (/usr/bin/x86_64-w64-mingw32). Is this a bug, or a feature? System data: OS: Debian jessie Linux/GNU i386 Installed GHC (for bootstrapping): version 7.6.3 GHC I'm trying to build: version 7.8.3 Regards Sven

2 1

Printing telnet stream to wx widget with conduit
by Tilmann 05 Oct '14

05 Oct '14

Hi, I have this little program that works 'sometimes'. It is supposed to connect to a server via telnet and print the incoming text to a wx textwidget. Usually I get an error message: ChessGui: <socket: 22>: hGetBufSome: illegal operation (handle is closed), but I acutally saw it working a few times... The whole thing is a bit out of my Haskell-league, so I´m a bit lost now. Any help is very appreciated! Best regards, Tilmann module Main where import Control.Concurrent (forkIO, killThread) import Control.Monad.IO.Class (MonadIO, liftIO) import Control.Monad.Trans.Resource import Data.Conduit import qualified Data.Conduit.Binary as CB import qualified Data.ByteString.Char8 as BS import Network (connectTo, PortID (..)) import System.IO import Graphics.UI.WX import Graphics.UI.WX.Types import Graphics.UI.WXCore.WxcDefs main = start gui gui = do f <- frame [] t <- textCtrlEx f (wxTE_MULTILINE .+. wxTE_RICH2) [font := fontFixed] e <- entry f [] set f [layout := boxed "console" (grid 5 5 [[floatLeft $ expand $ hstretch $ widget t] ,[expand $ hstretch $ widget e]])] telnet "freechess.org" 5000 t telnet :: String -> Int -> TextCtrl() -> IO () telnet host port t = runResourceT $ do (releaseSock, hsock) <- allocate (connectTo host $ PortNumber $ fromIntegral port) hClose liftIO $ mapM_ (`hSetBuffering` LineBuffering) [ hsock ] liftIO $ forkIO $ CB.sourceHandle hsock $$ (sink' t) return () sink' :: TextCtrl () -> Sink BS.ByteString IO () sink' textCtrl = do mstr <- await case mstr of Nothing -> return () Just str -> do text' <- liftIO $ (get textCtrl text) liftIO $ set textCtrl [text := text' ++ BS.unpack str ] sink' textCtrl

2 2

makeFields without lenses
by Nicola Gigante 05 Oct '14

05 Oct '14

Good morning to everyone. I really love what makeFields from Control.Lens.TH does: generating a typeclasse HasXXX for each field _typeXXX and instances of the class for each type that has a record field with the same name. However, it generates lenses, which at this time I don’t use in my little project. I'll learn to use them well sooner or later, I promise! In the meantime, is there some module out there than provides a template haskell function that do the same thing but generating simple accessor functions instead of lenses? Or can I configure the parameters of makeFieldsWith to generate simple functions instead of lenses? Another related question: if I use makeFields in more than one module, and different records have fields with the same name, the generated typeclasses will have the same name but will be different, because declared twice in different modules, am I right? Is there a way to use a unique typeclass in the whole project for every generated field of the same name? Thank you very much, Nicola

5 6

Several default implementations for instance methods
by Andreas Abel 04 Oct '14

04 Oct '14

Consider the following class for an overloaded pretty printer. For atomic data (numeric types, String etc.) one would implement prettyShow, for complex data either pretty or prettyPrec. > import Text.PrettyPrint > > class Pretty a where > pretty :: a -> Doc > prettyShow :: a -> String > prettyPrec :: Int -> a -> Doc Implementing one of these methods should be enough, giving default implementations for the other two. It is easy to get prettyShow and prettyPrec from pretty. > prettyShow = render . pretty > prettyPrec = const . pretty However, to define pretty from one of the others, I need two default implementations. > pretty = text . prettyShow > pretty = prettyPrec 0 Is there a way to get this to work? Workarounds (not entirely satisfactory): Technically, one could define a cycle of default implementations. Alternative 1: > pretty = prettyPrec 0 > prettyShow = render . pretty > prettyPrec _ = text . prettyShow Problem: Here, if pretty is defined, > prettyPrec _ = text . render . pretty instead of just > prettyPrec _ = pretty and (text . render) is not the identity (destroys inner document structure). Alternative 2: > pretty = text . prettyShow > prettyShow = render . prettyPrec 0 > prettyPrec _ = pretty Problem: Here, if prettyPrec is defined, > pretty = text . render . prettyPrec 0 instead of just > pretty = prettyPrec 0 I guess alternative 2 is worse than alternative 1, as one would usually define prettyPrec to get pretty, and not the otherway round. But none of these two alternatives really does the job. -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www2.tcs.ifi.lmu.de/~abel/

3 2