- Haskell-Cafe - Haskell.org

podcast?
by serialhex 21 Feb '12

21 Feb '12

Does anybody know of any good haskell/fp podcasts out there? i dont know if my googling skillz are just failing me, but i can't seem to find anything. thanks all! hex -- * my blog is cooler than yours: http://serialhex.github.com * The wise man said: "Never argue with an idiot. They bring you down to their level and beat you with experience." * As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow. ~Doug McIlroy No snowflake in an avalanche ever feels responsible. --- CFO: “What happens if we train people and they leave?” CTO: “What if we don’t and they stay?”

4 4

types and number of evaluation steps
by Heinrich Hördegen 21 Feb '12

21 Feb '12

Dear all, I have a question about evaluation with respect to types and currying. Consider this programm: import Debug.Trace -- add :: Integer -> Integer -> Integer add :: Int -> Int -> Int add x y = x + y f a b c = trace "b" (add x c) where x = trace "a" (add a b) main :: IO () main = do print (f 1 2 3) print (f 1 2 4) Compiled with ghc-7.0.3: $ ghc --make Main.hs -o main -O2 The function add has to types. When we use type Int -> Int -> Int, the programm produces "b a 6 b a 7" as output which shows that the x from the where clause in f is evaluated twice. However, when we use type Integer -> Integer -> Integer, this will give "b a 6 b 7" which shows that x is evaluated only once. This was rather unexpected to me. Why does the number of evaluation steps depend on a type? Can anybody explain this or give a hint? Thank you very much, Heinrich -- -- hoerdegen(a)funktional.info www.funktional.info --

6 11

(no subject)
by M. R 21 Feb '12

21 Feb '12

1 0

Conduit Error Output: Control.Monad.Trans.Resource.stateCleanup
by Lyndon Maydwell 21 Feb '12

21 Feb '12

Hi Michael, Café. I'm writing some code using the conduit library and am encountering the following error output (while the program appears to function correctly) when using Data.Conduit.Lazy. The error given is: > profile_simple_test_data: Control.Monad.Trans.Resource.stateCleanup: There is a bug in the implementation. The mutable state is being accessed after cleanup. Please contact the maintainers. A reduced code snippet that generates this error is (also attached): > import Control.Monad > import System.Environment > import Control.Monad.IO.Class (liftIO) > import System.IO > import Data.Conduit.Lazy > import Data.List (sort) > > import Data.Conduit > > import Prelude hiding (map) > > main = getArgs >>= process > > process args = mapM_ sorted args > > sorted x = runResourceT (lazyConsume $ sourceFeed x) >>= (mapM_ print . id) > > sourceFeed :: ResourceIO m => FilePath -> Source m String > sourceFeed file = sourceIO > (openFile file ReadMode) > hClose > (\h -> liftIO $ do > eof <- hIsEOF h > if eof > then return IOClosed > else fmap IOOpen $ hGetLine h) when run over any text file. I may be doing something inconsistent with the correct use of sourceIO or lazyConsume, however, I tried to follow the example at http://www.yesodweb.com/home/snoyberg/blogs/conduit/conduit/source/source.d… as closely as possible. Is this a bug, or simply an incorrect use of Conduit?

2 5

Streaming to JuicyPixels
by Myles C. Maxfield 21 Feb '12

21 Feb '12

Hello, I am interested in the possibility of using JuicyPixels for streaming images from the web. It doesn't appear to expose any of its internally-used Serialize.Get functionality, which is problematic for streaming - I would not like to have to stream the whole image into a buffer before the decoder can start decoding. Are there any plans on exposing this API, so I can use the runGetPartial function to facilitate streaming? In addition, does the library do much readahead? There's no point in exposing a Get interface if it's just going to wait until the stream is done to start decoding anyway. Thanks, Myles C. Maxfield

2 2

Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
by Anthony Clayden 21 Feb '12

21 Feb '12

> On 1/02/2012, at 11:38 AM, AntC wrote: > > As soon as you decide to make 'virtual record selectors' > > just ordinary functions (so they select but not update) > > , then you can see that field names are also just > ordinary functions (for selection purposes). So the > > semantics for field 'selection' (whether or not you use > > dot notation) is just function application. So > Type-Directed Name resolution is just instance resolution. > > So it all gets much easier. > > > Richard O'Keefe wrote: > ... Making f x > and x.f the same is pretty appealing, but it is imaginable > that the former might require importing the name of f from > a module and the latter might not. That is to say, it lets > f and .f have completely different meanings. Oh the joy! > Oh the improved readability! -- on some other planet, > maybe. > Hi Richard, I'm not sure I understand what you're saying. I'm proposing x.f is _exactly_ f x. That is, the x.f gets desugared at an early phase in compilation. If the one needs importing some name from a module, than so does the other. A 'one-sided dot doesn't mean anything. (Also, I feel vaguely nauseous even seeing it written down.) Under my proposal, the only thing .f could mean is: \z -> z.f which desugars to \z -> f z which means (by eta-reduction) f And to complete the story: the only thing (x.) could mean is: \g -> x.g So a use like: (x.) f -- or z f, where z = (x.) would desugar to f x which is the same as x.f A use like (x.)f (no spaces around the parens) would amount to the same thing. This is all so weird I'm inclined to say that one-sided dot is probably a syntax error, and reject it. It's too dangerously ambiguous between the syntax for 'proper' dot notation and function composition. Or is there something I'm not understanding? [Good to see another NZ'er on the list, by the way.] AntC

14 47

Simple GUI library to view JSON?
by dokondr 20 Feb '12

20 Feb '12

Please advise on a simple GUI library to display JSON data. A library that is easy to build both on Win, Linux and OsX. I need a scrollable view to show a list of JSON objects. Every object may contain other objects (recursively). List may have thousands of objects. Fields may have very long text values, so the view must also be scrollable in horizontal dimension. JSON object view should be click-able and look like on this example: { hey: "guy", anumber: 243, - anobject: { whoa: "nuts", - anarray: [ 1, 2, "thr<h1>ee" ], more: "stuff" }, awesome: true, bogus: false, meaning: null, link: "http://jsonview.com", } Where '-' before the field object indicates that object was expanded and '+' means collapsed object. Clicking on expanded fields should collapse them and vice verse. So for this example, clicking on 'anobject' should result in: { hey: "guy", anumber: 243, anobject: { ... } awesome: true, bogus: false, meaning: null, link: "http://jsonview.com", } In short I need a view similar to the one provided by JSONView plugin for Firefox: https://addons.mozilla.org/en-US/firefox/addon/jsonview/ Thanks a lot for any info, comments and ideas about this project!

3 4

[ANNOUNCE] HaTeX 3.2
by Daniel Díaz Casanueva 20 Feb '12

20 Feb '12

Hello, A new version (3.2) of HaTeX has been released today to Hackage: http://hackage.haskell.org/package/HaTeX-3.2 HaTeX is the LaTeX language syntax implementation done in Haskell. Key changes in this version are: + LaTeX parser implemented (so new dependency on parsec). + Greek alphabet added to AMSMath module. + New LaTeX package implemented: graphicx. + Function 'documentclass' changed. Further information on this release: http://deltadiaz.blogspot.com/2012/02/hatex-chapter-32.html Library homepage: http://dhelta.net/hprojects/HaTeX Thanks for reading, Daniel Díaz.

1 0

Nico de Bruijn dies at 93
by S D Swierstra 20 Feb '12

20 Feb '12

2 1

Re: [Haskell-cafe] Data.Array.Accelerate initialization timings
by Paul Sujkov 20 Feb '12

20 Feb '12

Yep. It doesn't help: generateArray1 n = Acc.use $ Acc.fromList (Acc.Z Acc.:. n*n*n) [0..n*n*n] still takes the same amount of time. I guess something's wrong elsewhere. On 20 February 2012 16:06, Alex Gremm <algremm(a)googlemail.com> wrote: > Hi Paul, > > even though I just started reading about Accelerate, it seems to me that > you didn't use the "use" method which according to [1] initiates > asynchronous data transfer from host to GPU. > > > Cheers, > Alex > > [1]: http://www.cse.unsw.edu.au/%7Echak/papers/acc-cuda.pdf > On 20/02/12 14:46, Paul Sujkov wrote: > > Hi everyone, > > > > since accelerate mail list seems to be defunct, I'm trying to ask > > specific questions here. The problem is: array initialization in > > Data.Array.Accelerate takes a 10x amount of time in contrast to both > > Data.Array and bare C++ CUDA array initialization. This can be due to > > Data.Array.Accelerate having two backends (however, it's own tests show > > that my nVidia card is CUDA-capable), but I'm not aware of how can I > > profile GPU to check whether it is used or not. Anyway, here's code: > > > > http://hpaste.org/64036 > > > > both generateArray (DIM3) and generateArray1 (DIM1) take the same amount > > of time to initialize array. I'd say the problem is in GPU memory > > copying time, but here's bare C++ code: > > > > http://hpaste.org/64037 > > > > which does exactly the same, but 10 times faster. I'm wandering what am > > I doing wrong and how to check if I really am. Thanks in advance if > > anyone can point me on my mistakes! > > > > -- > > Regards, Paul Sujkov > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Regards, Paul Sujkov

1 0