- Haskell-Cafe - Haskell.org

Maintaining lambdabot
by Jan Stolarek 21 Mar '13

21 Mar '13

Hi all, as some of you may have noticed Lambdabot doesn't build on GHC 7.6.1 due to OldException being removed (and a few other changes). I updated the code so that it builds on latest GHC release. The updated code is available here: https://github.com/killy9999/lambdabot/tree/upstream It builds on Linux, but I am not 100% certain that it will build on Windows. If it doesn't I will be grateful for reporting this (and any other) issues on the bug tracker: https://github.com/killy9999/lambdabot/issues The changes required to make the code run weren't as small as I initially thought they will be. In some places this resulted in a bit ugly code, but aside from that I think that everything should work correctly. Now I would like to do a bit of maintanance on the project, since the code is a bit of a mess and it could use some cleanup. My plans are: - clean up the package namespace by placing existing modules in Lambdabot module - integrate lambdabot-utils into lambdabot (already done) - reformat the code so that it's easier to read ans if time allows: - cleanup some messy code - update the package dependencies so that lambdabot relies on maintained libraries (e.g. I thought about replacing readline with haskeline). This changes would be quite invasive and code wouldn't be compatible with the lambdabot repo on haskell.org. So before I start making any of them I would like to hear from the community if such changes in the source code of lambdabot would be considered helpful and acceptable. Janek

7 29

package show needs QuickCheck<2.6?
by Johannes Waldmann 20 Mar '13

20 Mar '13

Hi, I noticed that compilation of mueval (recent: 0.8.2) breaks because show (0.5) cannot be built: it seems the type of Failure changed in QuickCheck (from 2.5 to 2.6). The build succeeds with --constraint 'QuickCheck<2.6' .

2 1

Does GHC 7.8 make targeting bare metal ARM any easier?
by Jeremy Shaw 20 Mar '13

20 Mar '13

There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar. Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot. With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box. Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc). I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked? - jeremy

4 3

ANN: LearnByHaking.org
by Deian Stefan 20 Mar '13

20 Mar '13

Hi cafe, I've been delaying the announcement of LearnByHacking.org as I wish to add more features, but some of you may be interested in it as is. The web app is inspired by and, to some degree, a lighter-weight clone of School of Haskell. I am currently using it as glorified blog that provides a means for collaborating with others on posts and include active code. For those unfamiliar with SoH, that is, code that users can execute with a single click and modify. There are lots of things on the TODO list, so if anybody wants to hack, please join in. Cheers, Deian

1 0

Streaming bytes and performance
by Konstantin Litvinenko 20 Mar '13

20 Mar '13

Hi All! I tune my toy project for performance and hit the wall on simple, in imperative world, task. Here is the code that model what I'm trying to achieve import qualified Data.ByteString.Lazy as L import Data.Word8(isSpace) import Data.Word import Control.Monad.State type Stream = State L.ByteString get_byte :: Stream (Maybe Word8) get_byte = do s <- get case L.uncons s of Nothing -> return Nothing Just (x, xs) -> put xs >> return (Just x) main = do f <- L.readFile "test.txt" let r = evalState count_spaces f print r where count_spaces = go 0 where go a = do x <- get_byte case x of Just x' -> if isSpace x' then go (a + 1) else go a Nothing -> return a It takes the file and count spaces, in imperative way, consuming bytes one by one. The problem is: How to rewrite this to get rid of constant allocation of state but still working with stream of bytes? I can rewrite this as one-liner L.foldl, but that doesn't help me in any way to optimize my toy project where all algorithms build upon consuming stream of bytes. PS. My main lang is C++ over 10 years and I only learn Haskell :)

7 20

Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi
by Jesper Särnesjö 20 Mar '13

20 Mar '13

Hi everybody, This started out on haskell-beginners, as a question about poor performance for a Haskell program using OpenGL. Thanks to a few good suggestions there, I've managed to figure out more or less what the underlying problem is, but not its cause. In short, I have two programs, one written in Haskell [1] and one written in C [2], that consist of calls to the same functions, in the same order, to the same C library, but which do not exhibit the same behavior. Further, the Haskell program behaves differently when compiled using GHC, and when run in GHCi. I would like to know why this is, and how to fix it. A bit of background. My original program used the GLFW library to create an OpenGL rendering context, and rendered a 3D model using OpenGL. I noticed that this program had very high CPU usage, when I expected it to do most of its work on the GPU [3]. The reason for the high CPU usage turned out to be that the program was in fact using a software implementation of OpenGL [4]. My machine, a MacBook Pro running Mac OS X 10.8.2, has two GPUs, a discrete (more powerful) and an integrated one (more energy-efficient). The latter implements a larger part of OpenGL in software, and the OS is supposed to switch transparently between the two. In particular, it is supposed to switch to the discrete GPU when a program tries to use OpenGL features not supported by the integrated GPU [5]. I discovered that while this all worked as intended when running the C version of my program, it did not work quite so well for the Haskell program [6], which would get stuck with a rendering context on the integrated GPU, which in practice meant a software implementation and poor performance. I reduced both programs to fairly minimal test cases. Now, each program simply configures and creates a rendering context, checks if it is hardware-accelerated (for the configuration used, on my machine, this implies that the system has switched to the discrete GPU), and then terminates. This is all done using calls to the GLFW C library. The C program succeeds. The Haskell program fails if compiled (with GHC 7.4.2) and run, but succeeds if run in GHCi. Further, by monitoring which GPU is active, using gfxCardStatus [7] and the system console, I've established that the switch happens immediately following the execution of glfwOpenWindow, for the C program and the Haskell program when run in GHCi. For the compiled Haskell program, the switch is delayed by roughly a second. This delay appears to be what causes the program to get stuck on the integrated GPU. Now, there are a lot of moving parts involved, and many places where things could go wrong, making it tricky to even say where the problem is. Still, a Haskell program consisting entirely of foreign function calls in the IO monad, should surely behave the same as a C program consisting of the same calls? Is this caused by lazy evaluation, and if so, of what? Why does it work correctly in GHCi? I've bashed my head against this for some time now, and have run out of good ideas. I would really appreciate any input that lets me solve this, and get back to the fun parts of 3D programming. ;) To reproduce this, you'll need a Mac that has two GPUs (most of them does, these days). I run Mac OS X 10.8.2, and another user reproduced this on 10.7.5 [8]. You'll also need the GLFW library [9], which can be built from source or installed using Homebrew. Please let me know if I can provide any more information. -- Jesper Särnesjö http://jesper.sarnesjo.org/ [1] https://gist.github.com/sarnesjo/5151894#file-glfw_test-hs [2] https://gist.github.com/sarnesjo/5151894#file-glfw_test-c [3] http://www.haskell.org/pipermail/beginners/2013-March/011557.html [4] http://www.haskell.org/pipermail/beginners/2013-March/011560.html [5] http://developer.apple.com/library/mac/#qa/qa1734/_index.html%23//apple_ref… [6] http://www.haskell.org/pipermail/beginners/2013-March/011601.html [7] http://gfx.io [8] http://www.haskell.org/pipermail/beginners/2013-March/011563.html [9] http://www.glfw.org

6 11

Associated types for number coercion
by Christopher Done 19 Mar '13

19 Mar '13

>From the paper Fun with Type Funs, it's said: > One compelling use of such type functions is to make type > coercions implicit, especially in arithmetic. Suppose we want to be able to > write add a b to add two numeric values a and b even if one is an Integer > and the other is a Double (without writing fromIntegral explicitly). And then an Add class is defined which can dispatch at the type-level to appropriate functions which resolve two types into one, with a catch-all case for Num. Has anyone put this into a package, for all common arithmetic operations? I would use it. Doing arithmetic stuff in Haskell always feels labored because of having constantly convert between number types.

3 4

Fwd: Now Accepting Applications for Mentoring Organizations for GSoC 2013
by Johan Tibell 19 Mar '13

19 Mar '13

[bcc: haskell(a)haskell.org] We should make sure that we apply for Google Summer of Code this year as well. It's been very successful in the previous year, where we have gotten several projects funded every year. -- Johan ---------- Forwarded message ---------- From: Carol Smith <carols(a)google.com> Date: Mon, Mar 18, 2013 at 12:00 PM Subject: Now Accepting Applications for Mentoring Organizations for GSoC 2013 To: Google Summer of Code Announce < google-summer-of-code-announce(a)googlegroups.com> Hi all, We're pleased to announce that applications for mentoring organizations for Google Summer of Code 2013 are now being accepted [1]. If you'd like to apply to be a mentoring organization you can do so via Melange [2]. If you have questions about how to use Melange, please see our User's Guide [3]. Please note that the application period [4] closes on 29 March at 19:00 UTC [5]. We will not accept any late applications for any reason. [1] - http://google-opensource.blogspot.com/2013/03/mentoring-organization-applic… [2] - http://www.google-melange.com [3] - http://en.flossmanuals.net/melange/ [4] - http://www.google-melange.com/gsoc/events/google/gsoc2013 [5] - http://goo.gl/xmQMJ Cheers, Carol -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Announce" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-summer-of-code-announce%2Bunsubscribe(a)googlegroups.com. To post to this group, send email to google-summer-of-code-announce(a)googlegroups.com. Visit this group at http://groups.google.com/group/google-summer-of-code-announce?hl=en. For more options, visit https://groups.google.com/groups/opt_out.

3 2

Re: [Haskell-cafe] attoparsec and backtracking
by oleg＠okmij.org 19 Mar '13

19 Mar '13

Wren Thornton wrote: > I had some similar issues recently. The trick is figuring out how to > convince attoparsec to commit to a particular alternative. For example, > consider the grammar: A (B A)* C; where if the B succeeds then we want to > commit to parsing an A (and if it fails then return A's error, not C's). Indeed. Consider the following (greatly simplified) fragment from the OCaml grammar | "let"; r = opt_rec; bi = binding; "in"; x = expr LEVEL ";" -> | "function"; a = match_case -> | "if"; e1 = SELF; "then"; e2 = expr LEVEL "top"; "else"; e3 = expr LEVEL "top" -> ... | "false" -> | "true" -> It would be bizarre if the parser -- upon seeing "if" but not finding "then" -- would've reported the error that `found "if" when "true" was expected'. Many people would think that when the parser comes across "if", it should commit to parsing the conditional. And if it fails later, it should report the error with the conditional, rather than trying to test how else the conditional cannot be parsed. This is exactly the intuition of pattern matching. For example, given > foo ("if":t) = case t of > (e:"then":_) -> e > foo _ = "" we expect that foo ["if","false","false"] will throw an exception rather than return the empty string. If the pattern has matched, we are committed to the corresponding branch. Such an intuition ought to apply to parsing -- and indeed it does. The OCaml grammar above was taken from the camlp4 code. Camlp4 parsers http://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial002.html#toc6 do pattern-matching on a stream, for example # let rec expr = parser [< 'If; x = expr; 'Then; y = expr; 'Else; z = expr >] -> "if" | [< 'Let; 'Ident x; 'Equal; x = expr; 'In; y = expr >] -> "let" and raise two different sort of exceptions. A parser raises Stream.Failure if it failed on the first element of the stream (in the above case, if the stream contains neither If nor Let). If the parser successfully consumed the first element but failed later, a different Stream.Error is thrown. Although Camlp4 has many detractors, even they admit that the parsing technology by itself is surprisingly powerful, and produces error messages that are oftentimes better than those by the yacc-like, native OCaml parser. Camlp4 parsers are used extensively in Coq. The idea of two different failures may help in the case of attoparsec or parsec. Regular parser failure initiates backtracking. If we wish to terminate the parser, we should raise the exception (and cut the rest of the choice points). Perhaps the could be a combinator `commit' that converts a failure to the exception. In the original example A (B A)* C we would use it as A (B (commit A))* C.

1 0

ANNOUNCE: HaTeX-3.5 - New version of the LaTeX library
by Daniel Díaz Casanueva 19 Mar '13

19 Mar '13

Hi readers! A new version of HaTeX has just been released. More math symbols and utilities and a new attoparsec-based parser. This new version also includes a new matrix renderer. A summary of the changes: http://deltadiaz.blogspot.com/2013/03/hatex-35.html The package in Hackage: http://hackage.haskell.org/package/HaTeX-3.5 For those who don't know, HaTeX is a combinator library for LaTeX code. Read more in the manual: https://github.com/downloads/Daniel-Diaz/HaTeX-Guide/HaTeX-Guide.pdf I recommend to HaTeX users to upgrade to this new version. Good luck, Daniel Díaz. -- E-mail sent by Daniel Díaz Casanueva let f x = x in x

2 1