October 2008 - Haskell-Cafe

Reader monad, implicit parameters, or something else altogether?
by Bjorn Buckwalter 16 Dec '08

16 Dec '08

All, I have a growing amount of astrodynamics code that relies on various physical "constants". The problem with these so called "constants" are that they either aren't really constants or aren't well known. An example is the leap second table (see Data.Time.Clock.TAI). I'd like to be able to fetch current values of these constants at runtime and make them accessible to my astrodynamics functions by some means. To clarify, once initialized the constants will be considered constant for the remainder of the program. I'd store the constants in a data structure along the lines of: > data AstroData a = AstroData > { mu_Earth :: GravitationalParameter a > , leapSeconds :: LeapSecondTable > } I would like to know if there is any consensus on what is the best way to make such a data structure accessible in pure functions. Passing it explicitly would be a mess. It seems that two options are to use either a Reader monad or implicit parameters. Using a Reader monad is straight forward enough though it requires writing/converting code in/to monadic style and adds some clutter to the formulae. It seems implicit parameters could be cleaner but I've seen them referred to as everything from evil to "just what you need" and rendering the Reader monad obsolete... What do you people recommend? Thanks, Bjorn Buckwalter

5 7

Problem with haddock 2.3.0 (again)
by Leonidas Fegaras 15 Dec '08

15 Dec '08

Sorry for the previous message. I am sending it again. Dear fellow haskell programmers, I tried to install a package in hackageDB and got a strange error from haddock: haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing Here is the complete log: http://hackage.haskell.org/packages/archive/HXQ/0.10.0/logs/failure/ghc-6.8 When I build it using Cabal 1.6.0.1 and haddock 2.2.2 using 'runhaskell Setup.lhs haddock', it works fine (I get warnings but no errors). Also haddock 2.3.0 is not available in hackageDB so I can't test it myself. Where I can find haddock 2.3.0? Thank you for your help, Leonidas Fegaras _________________________________________________________________ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008

7 29

Password hashing
by Bit Connor 26 Nov '08

26 Nov '08

Hello, What library can be used to securely hash passwords? From what I understand, the "bcrypt" algorithm is what the experts recommend. It is described in the paper: http://www.openbsd.org/papers/bcrypt-paper.ps I couldn't find a haskell library for this. There is a BSD licensed C implementation that looks very simple here: http://www.mindrot.org/projects/py-bcrypt/ A translation to haskell should be straight forward. Alternatively, a haskell bcrypt library could directly use this implementation and provide a very light FFI wrapper. Any thoughts?

17 31

Hackage policy question
by Iavor Diatchki 20 Nov '08

20 Nov '08

Hi, I just noticed that hackage has introduced a new policy to disallow changes to a package without bumping the version. I understand that this is probably a good idea for changes to the source code, but it really would be nice to have a backdoor that allows for other changes. For example, I just uploaded a package, and realized that I forgot to add a home-page entry in the cabal file. I do not plan to increase the version number of my application, only so that I can upload a new version (the source code has not changed after all!). I can imagine similar problems related to fixing typos in the description, and other fixes to the meta-data. So, could we please revert to the old policy? (if we really want to be fancy, the hackage upload script could check that the source code, and other fields, such as LICENSE have not changed, as these should really bump the version... in the mean time though, I think just being responsible members of the community would work just as well!). -Iavor

8 23

performance difference for binary-0.4.3.1 with ghc-6.8.3 and ghc-6.10
by John Lato 08 Nov '08

08 Nov '08

Hello, I was experimenting with using ghc-6.10.0.20081007 on a project, and it seems that binary-0.4.3.1 has markedly worse performance in certain cases. With the following simple test: > import qualified Data.ByteString.Lazy as L > import Data.Binary > import Data.Binary.Get > import Control.Monad > > main :: IO () > main = do > b <- L.readFile "some_binary_file" > putStrLn $ show $ runGet getter b > getter :: Get [Word16] > getter = replicateM 1000000 getWord16le running this program compiled with ghc-6.10 takes about 4 times as long (and consumes much more memory) as when compiled with ghc-6.8.3. The extra time appears to be proportional to the number of elements processed in the Get. Running the programs with -hT shows a clear memory difference, which I think is the source of the problem. I've placed pdfs of that output at https://webspace.utexas.edu/latojw/data/ The difference seems to manifest itself only when the elements are actually processed; changing "show $ runGet " to "show $ length $ runGet " is slightly faster in 6.10. I was working on an Intel Mac with OS 10.4, binary-0.4.3.1, and bytestring-0.9.1.4. Can anyone confirm this, or suggest what might be the difference? Thank you, John Lato

6 9

ghc-6.11 + OpenGL/GLUT crashes on WinXP
by Conal Elliott 06 Nov '08

06 Nov '08

I'm getting crashes from ghc-6.10.0.20081007 and ghc-6.11.20081024 when doing a very simple GLUT program (below) with OpenGL-2.2.1.1 and GLUT-2.1.1.2 (the latest from Hackage), running on WinXP. It works fine on ghc-6.9.20080622 . I'd appreciate hearing about other attempts with these versions on Windows systems. Thanks, - Conal import Graphics.UI.GLUT main :: IO () main = do putStrLn "Initializing" getArgsAndInitialize return ()

6 9

two problems with Data.Binary and Data.ByteString
by Tim Newsham 05 Nov '08

05 Nov '08

I have a program that read in and populated a large data structure and then saved it out with Data.Binary and Data.ByteString.Lazy.Char8: saveState db = B.writeFile stateFile =<< encode <$> atomically (readTVar db) when I go to read this in later I get a stack overflow: loadState db = do d <- decode <$> B.readFile stateFile atomically $ writeTVar db d Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. or from ghci: d <- liftM decode (Data.ByteString.Lazy.Char8.readFile "savedState.bin") :: IO InstrsDb fromList *** Exception: stack overflow The data type I'm storing is a Map (of maps): type DailyDb = M.Map Date Daily type InstrsDb = M.Map String DailyDb What's going on here? Why is the system capable of building and saving the data but not in reading and umarhsalling it? What is the proper way to track down where the exception is happening? Any debugging tips? I also noticed another issue while testing. If my program loads the data at startup by calling loadState then all later calls to saveState give an error: Log: savedState.bin: openFile: resource busy (file is locked) this does not occur if the program wasnt loaded. My best guess here is that B.readFile isnt completing and closing the file for some reason. Is there a good way to force this? Tim Newsham http://www.thenewsh.com/~newsham/

10 49

Network.FastCGI does not emit stderr outputs to lighttpd's error.log?
by Agent Zhang 04 Nov '08

04 Nov '08

Hi, I'm trying Network.FastCGI + lighttpd 1.4.9 to develop a RESTful service platform. I've found that stderr (especially those from Debug.Trace) get lost in the error.log file. But plain CGI mode with Network.CGI works perfectly (all stderr outputs appear in error.log). Besides, my Perl fastcgi script also logs stderr with the same lighttpd. So it does seem that my lighttpd's mod_fastcgi module is OK. Is this a known issue in the Haskell fastcgi library? Is there a workaround or a fix? Thanks in advance :) Cheers, -agentzh

3 4

Cairo build fail on OS X Leapord
by Jefferson Heard 03 Nov '08

03 Nov '08

Installing gtk2hs from MacPorts on a clean mac: 2 -I/usr/X11R6/include svgcairo/Graphics/Rendering/Cairo/SVG.chs:201:2: Couldn't match expected type `()' against inferred type `CInt' Expected type: Render () Inferred type: Render CInt In the expression: liftIO $ (\ (SVG arg1) (Cairo arg2) -> withForeignPtr arg1 $ \ argPtr1 -> rsvg_handle_render_cairo argPtr1 arg2) svg cr In the expression: do cr <- ask liftIO $ (\ (SVG arg1) (Cairo arg2) -> withForeignPtr arg1 $ \ argPtr1 -> rsvg_handle_render_cairo argPtr1 arg2) svg cr make[1]: *** [svgcairo/Graphics/Rendering/Cairo/SVG.o] Error 1 rm svgcairo/Graphics/Rendering/Cairo/SVG.hs make: *** [all] Error 2 Error: Status 1 encountered during processing. -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards

2 3

Poll: Do you need to be able to build darcs from source on GHC 6.6?
by Jason Dagit 02 Nov '08

02 Nov '08

Hello, I would like to find out if any darcs users who build from the source are still using ghc 6.6? If you are such a user, please let me know. Thanks, Jason

11 25