- Haskell-Cafe - Haskell.org

Generating Code
by L Corbijn 12 Dec '11

12 Dec '11

Hello, In an attempt to reduce the amount of boring repetitive work to update the OpenGLRaw package I've created a generator to do it partially for me. It currently uses haskell-src-exts for representing the haskell source of the modules. Though haskell-src-exts does an excellent job for representing haskell source, it seems to be more aimed at parsing haskell source and doing something with it, rather than generating it. For cpp macros, say for the use of different calling conventions used, can't be used directly, nor is there a really good way to use comments (at least so it seems to me). So I'm interested if there are other libraries that are more suitable to the task of generating haskell code for library use, and thus generate 'human readable' exported code (so no TH). I'm also interested in how other projects generate code for their packages. Greetings, Lars Corbijn

10 15

ANNOUNCE: smallcheck-0.6; test-framework-smallcheck-0.1
by Roman Cheplyaka 12 Dec '11

12 Dec '11

I'm pleased to announce a new release of SmallCheck. The highlights for this release are: * Default Generic implementation of Serial instance, contributed by Bas van Dijk This means that you don't need to write instances by hand for your types to generate test values for them. See [1] for the details. [1]: http://hackage.haskell.org/packages/archive/smallcheck/0.6/doc/html/Test-Sm… * Revised, organised into modules and documented API * Integration with test-framework, through test-framework-smallcheck package It allows to organize SmallCheck properties into a test suite (possibly together with HUnit or QuickCheck tests), apply timeouts, get nice statistics etc. Thanks to Max Bolingbroke for cooperation on this front. Please refer to the README for more information about SmallCheck: https://github.com/feuerbach/smallcheck/blob/master/README.md Hackage links: http://hackage.haskell.org/package/smallcheck-0.6 http://hackage.haskell.org/package/test-framework-smallcheck-0.1 -- Roman I. Cheplyaka :: http://ro-che.info/

1 0

Sharing a room for the CRA-W/CDC/SIGPLAN Mentoring Workshop at POPL?
by Joachim Breitner 12 Dec '11

12 Dec '11

Hi, I will attend the CRA-W/CDC/SIGPLAN Mentoring Workshop at POPL next year, and will have to share a room with another attendee. As we can give preferences, I was wondering if another Haskeller might be in the same position and interested in sharing a room. Greetings, Joachim -- Joachim "nomeata" Breitner mail(a)joachim-breitner.de | nomeata(a)debian.org | GPG: 0x4743206C xmpp: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/

1 0

10th Ghent Functional Programming Group Meeting on Thursday, December 15, 2011 at 19h30
by Jasper Van der Jeugt 12 Dec '11

12 Dec '11

Dear All, We would like to remind you of the 10th Ghent Functional Programming Group (GhentFPG) meeting, which will take place this Thursday, December 15, 2011, at 19h30 in the Technicum building of Ghent University (Sint-Pietersnieuwstraat 41, 9000 Gent). This meeting, we will focus on tackling some interesting problems with the elegance of functional programming. We will try to post the problems to this mailing list at least two days in advance. As with the previous meeting, the meeting room is still unreachable through the regular building entrance because of construction works. Hence, attendees need to take the alternative side entrance. This entrance can be found on the right side (as seen from the street) of the building -- it will remain open until 20:00. If you walk up to the Technicum building and go right at the bicycle stands, you should see “Ingang Blok 1 & Blok 2” indicated. Follow this, and you’ll be able to get inside, at which point you’ll see arrows pointing to the meeting room. For safety measures the blue doors will be locked, so if you arrive after 19:30, please give us a call at +32 (0) 9 264 3370, so we can come and open the doors for you. P.S. we would also like to remind you that you are all certainly welcome at the talk about "Real-World Functional Programming @ Incubaid", organized by Tom Schrijvers for his course on Functional & Logic Programming at Ghent University. For more details see [1]. [1]: https://groups.google.com/d/topic/ghent-fpg/csUnMX08WKc/discussion Hope to see you then! The GhentFPG Organizing Committee.

1 0

Hardware description in Haskell.
by Serguey Zefirov 12 Dec '11

12 Dec '11

I would like to introduce my over-than-two years long project, HHDL: http://thesz.mskhug.ru/svn/hhdl/hackage/hhdl/ (I prefer to pronounce it as a ha-ha-dee-el, this way it is more fun) It allows one to create digital hardware description in Haskell and then generate VHDL code (Verilog is on the way). Okay, it would allow one to do all that some day. I hope it will come sooner than later. I try to make all wires as typed as I can and to support algebraic types with patetrn matching. I wrote a simple example to demonstrate some of those facilities: http://thesz.mskhug.ru/svn/hhdl/hackage/hhdl/src/Hardware/HHDL/Examples/Run… This is a simple accumulator that accepts a Maybe Word8 input. The resulting VHDL is very wordy, but looks superficially correct. I wrote two posts about HHDL: http://thesz.livejournal.com/1284055.html - slightly outdated as HHDL now generates VHDL that typechecks and allows one to name inputs and outputs http://thesz.livejournal.com/1284541.html - motivation behind HHDL There is no package for Hackage, because I do not feel HHDL is worth it right now. For example, I tested it on ghc 6.12.1, not later versions, the library code is messy. But HHDL is good enough for some scrutiny and critique by Haskell users who is into hardware description.

2 2

[ANNOUNCEMENT] xmobar 0.14
by Jose A. Ortega Ruiz 12 Dec '11

12 Dec '11

I'm happy to announce the release of xmobar 0.14. Xmobar is a text-based, minimalistic status bar for linuxy systems, written in Haskell. See http://projects.haskell.org/xmobar for details. Many, many thanks to the many, many contributors, and apologies for taking so long to put their code and fixes under a new release. In this episode: _New features_ - New brightness monitor, courtesy of Martin Perner. - New DateZone plugin, for configurable timezone and localized datetimes, also by Martin. - New keyboard layout monitor (Kbd). Yes, by Martin. - Rewrite of the event handling ([issue 53], [issue 57]), you guessed it. - Cpu monitor now also reports `iowait` field ([issue 55]). - Battery monitor: the full charge file is now settable in the monitor arguments (olpc systems use `charge_full_design`; see [issue 62]). _Bug fixes_ - [issue 45]: Fix for crashes with AC status changes in battery monitor. - [issue 48]: The <quality> field of Wireless behaves like a percentage. - [issue 50]/[issue 61]: `MPD` monitor now works with libmpd 0.6. - [issue 60]: Fixes for crashes on power resume for battery monitor. - Template sections without fields are now correctly displayed. - Catch errors when reading battery status (Ben Boeckel). - Compilation issues with ghc 7.x (Sergei Trofimovich). - Fixes for CoreTemp monitor in new kernels (Norbert Zeh). - Fix for pulseaudio problems in volume monitor (Martin Perner). - Fix for parsing errors when a `Run` entry ended in an array (Martin). - Fixed compilation in OpenBSD (Ivo van der Sangen). [issue 45]: http://code.google.com/p/xmobar/issues/detail?id=45 [issue 48]: http://code.google.com/p/xmobar/issues/detail?id=48 [issue 50]: http://code.google.com/p/xmobar/issues/detail?id=50 [issue 53]: http://code.google.com/p/xmobar/issues/detail?id=53 [issue 55]: http://code.google.com/p/xmobar/issues/detail?id=55 [issue 57]: http://code.google.com/p/xmobar/issues/detail?id=57 [issue 60]: http://code.google.com/p/xmobar/issues/detail?id=60 [issue 61]: http://code.google.com/p/xmobar/issues/detail?id=61 [issue 62]: http://code.google.com/p/xmobar/issues/detail?id=62 Cheers, jao

7 15

web-routes-quasi: Generating a route type
by Ertugrul Söylemez 11 Dec '11

11 Dec '11

Hello there, I'm trying to use the web-routes-quasi package outside of Yesod. Is there any documentation on how to use TH to generate a route type just like Yesod does? Or is that a Yesod-specific feature? I don't need the actual automatic dispatch or anything, just a type to work with. If it's not possible, I will just go ahead and (ab-) use the constructor strings. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

2 1

Munich Haskell Meeting
by Heinrich Hördegen 11 Dec '11

11 Dec '11

Dear all, the doodle poll for the next Haskell get-together indicates, that we should meet on Tuesday, 13 Dec 2011, 19h30 at Cafe Puck: http://www.doodle.com/x6x4sgnemc35myq3 I will reserve tables. For all those who cannot join, sorry, but we hope to meet you next year. Check out the dates: http://www.haskell-munich.de/dates So, let's meet at Tuesday for the last time this year. Heinrich -- -- hoerdegen(a)funktional.info www.funktional.info --

1 0

Hexpat: Lazy I/O problem with huge input files
by Aleksandar Dimitrov 11 Dec '11

11 Dec '11

Hello Haskell Cafe, I really hope this is the right list for this sort of question. I've bugged the folks in #haskell, they say go here, so I'm turning to you. I want to use Hexpat to read in some humongous XML files (linguistic corpora,) since it's the only Haskell XML library (I could find) that takes ByteStrings as input. I stumbled on a problem when using one of the examples from the docs of Text.XML.Expat.Tree. The "cookbook recipe" there suggests *first* processing the data, and only then looking into the parser error to see if there has been an error. I understand this should prevent the parse tree from being fully evaluated before use. Unfortunately, that is not what happens on my system (ghc 6.12.1, if that's of importance.) This is the code from the docs, that I modified to read files: > import Text.XML.Expat.Tree > import System.Environment (getArgs) > import Control.Monad (liftM) > import qualified Data.ByteString.Lazy as C >· > -- This is the recommended way to handle errors in lazy parses > main = do > f <- liftM head getArgs >>= C.readFile > let (tree, mError) = parse defaultParseOptions f > print (tree :: UNode String) >· > -- Note: We check the error _after_ we have finished our processing > -- on the tree. > case mError of > Just err -> putStrLn $ "It failed : "++show err > Nothing -> putStrLn "Success!" Given a 42M test file, an invocation like this: % ghc --make -O2 Hexpat.hs % ./Hexpat input.xml > dump.xml will gobble up some 2Gigs of RAM (at least. I usually kill it before it starts thrashing the swap space, since that almost crashes my entire machine.) If I remove the last 3 lines: > import Text.XML.Expat.Tree > import System.Environment (getArgs) > import Control.Monad (liftM) > import qualified Data.ByteString.Lazy as C > > main = do > f <- liftM head getArgs >>= C.readFile > let (tree, mError) = parse defaultParseOptions f > print (tree :: UNode String) the same invocation and input file barely uses a megabyte or two of RAM and finishes really quickly. Why is that? Is this a mistake in the Hexpat docs, or am I doing something wrong? Lazy IO has always been a little bit of a mystery to me, and just when I thought I had it... Thanks for any help on the matter! Aleks

3 3

Beginning Data.Lens tutorial
by Henry Laxen 10 Dec '11

10 Dec '11

Dear Group, If you haven't used lenses before, (as I hadn't until recently) you may find this helpful: http://www.nadineloveshenry.com/haskell/lensExamples.html Best wishes, Henry Laxen

1 0