- Haskell-Cafe - Haskell.org

Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882)
by Ravi Nanavati 12 Dec '09

12 Dec '09

---------- Forwarded message ---------- From: Ravi Nanavati <ravi_n(a)alum.mit.edu> Date: Sat, Dec 12, 2009 at 1:44 AM Subject: Next meeting: December 17th at MIT (32-G882) To: bostonhaskell(a)googlegroups.com I'm pleased to announce the December meeting of the Boston Area Haskell Users' Group. The meeting has been scheduled for Thursday, December 17th from 7pm to 9pm. Like recent meetings, it will be held in the MIT CSAIL Reading Room (32-G882, i.e. a room on the 8th floor of the Gates Tower of the MIT's Stata Center at 32 Vassar St in Cambridge, MA). Based on the responses to my previous message, our featured presenter will be Ryan Newton who will talk about the Intel Concurrent Collections for Haskell. Following his presentation, we will have our traditional break. After the break, we're going to try a joint programming exercise involving the collections. If anyone has a suggestion for an interesting programming exercise that would take advantage of the collections, please speak up (since otherwise Ryan and I will see what we can come up with next week). The December attendance poll is at: http://doodle.com/p2zcnca6k39iptb4 As always, responding to this poll will help with two things: 1. Getting an idea of what fraction of the Boston-area Haskell community can and can't attend this meeting (to help with future scheduling). 2. Giving me an estimated count of attendees, since I have talked my wife into baking some more goodies and bringing drinks again. Helping with BostonHaskell (besides volunteering to speak at future meetings): 1. Sponsorship of refreshments is still being eagerly solicited (especially as, for personal reasons, the Cupcake Fund is running low). 2. Please let me know if you're willing to arrive early (6:30pm) to stand by the door and let people into the 8th floor. I'm guessing 1 or 2 volunteers is enough here. 3. If someone is willing to edit the HaskellWiki page, post to reddit or otherwise publicize the meeting please just go ahead and do that (especially as I'm sending this out on the later side). If you have any questions about the meeting please send them to them BostonHaskell mailing list: bostonhaskell(a)googlegroups.com or contact me directly. I look forward to seeing many Boston-area Haskellers at the December meeting! Thank you, - Ravi Nanavati

3 2

"--" comments
by michael rice 12 Dec '09

12 Dec '09

I'm just noticing that "--" comments don't seem to work properly when the first character following them is a '*'. Michael --*I like asterisks --*I like asterisks --*I like asterisks --*I like asterisks double x = x+x Prelude> :l double [1 of 1] Compiling Main ( double.hs, interpreted ) double.hs:1:0: parse error on input `--*' Failed, modules loaded: none. Prelude>

4 5

wiki in hackage
by Andrew U. Frank 12 Dec '09

12 Dec '09

i think to add a wiki to each package is a great idea. as a default, it could be started automatically by uploading to hackage and filled with the readme.txt file (if availble) in the tar uploaded. if it is empty and exist, it is a point to check for when a package does not install immediately. alternatively, one has to search the web to see if there is some place with notices about this package. i would have loved to see wiki's for packages to post my result of work- arounds for problems with dependencies, small changes in source code etc. that could be posted there till the maintainer finds time to produce a new version. great idea! andrew frank

1 0

hledger 0.7 released
by Simon Michael 12 Dec '09

12 Dec '09

I'm pleased to announce hledger 0.7. Thanks to Marko Kocić who contributed many fixes for hlint warnings. To install/upgrade: cabal update && cabal install hledger [-fweb] [- fvty] Documentation: http://hledger.org Release notes: * price history support (first cut): P directives now work, though differently from c++ ledger. Each posting amount takes its fixed unit price from the price history (or @) when available. This is simple and useful for things like foreign currency expenses (but not investment tracking). Like ledger, balance and register don't show amount prices any more, and don't separate differently-priced amounts. Unlike ledger, print shows all amount prices, and supports -B. * --effective option, will use transactions' effective dates if any * convert: new rules file format, find/create rules file automatically, more robust parsing, more useful --debug output * print: always sort by date, fix long account name truncation, align amounts, show end of line comments, show all amounts for clarity (don't elide the final balancing amount) * ui: use vty 4, fixes non-ascii and gnome terminal problems (issues #3, #4) * web: allow data entry, react to data file changes, better layout, help links, remove histogram command and filter fields for now, fix bad localhost redirect, filter form did not work in eg firefox (issue #7), reset link did not work in all browsers * parsing: require whitespace between date and status code, allow (and ignore) a time in price records, better error messages, non-zero exit code on parse failure * display non-ascii error messages properly (issue #5) * fix an arithmetic bug that occasionally rejected valid transactions * fix a regex bug in showtree * don't break if HOME is undefined * --debug now implies --verbose * add functional tests like ledger's, use test-framework for speedy running, release shelltestrunner as a separate package * many hlint cleanups (Marko Kocić) * many site and documentation updates Stats: 2 contributors, 175 days since release, 182 commits, 3320 non-test code lines, 97 tests, 53% test coverage, performance: similar (http://hledger.org/profs/200912111852.bench) Best, -Simon

1 0

Re: [Haskell-cafe] Why?
by Janis Voigtländer 12 Dec '09

12 Dec '09

Andrew Coppin wrote: > On the other hand, turn up the optimisation settings on a C compiler > high enough and the program breaks. Somewhere the compiler elides a > second call to a function which actually happens to have some > side-effect that the compiler isn't aware of, and your stream is now one > byte out of alignment, or whatever. Fiddling with optimisation settings > in GHC may make your program slow to a crawl rather than go faster, but > it *never* makes it segfault on startup. Note, though, that "slow to crawl" may go as far as "not terminate". GHC's optimizer can make a terminating program nonterminating. For some discussion, see: http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion#Discussi… In fact, one can also make up examples where turning on optimization lets GHC transform a "good" program into one halting with an arbitrary error (division by zero, say). The recipe for (artificial) such examples can be found in footnote 2 of: http://www.iai.uni-bonn.de/~jv/TUD-FI09-06.pdf The error "in the wild" that is mentioned on the wiki page occurred in the context of the stream fusion library development. Best regards, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:jv@iai.uni-bonn.de

1 0

Using Atom's task scheduler for existing C code.
by Tom Hawkins 12 Dec '09

12 Dec '09

Today we were working on integrating Atom code with some hand-written C, and one of my colleagues posed the question: Is it possible to use Atom just for its task scheduler for existing C code? This turns out to be very simple. It just requires a few combinators built on top of 'action'. -- Call a C function with type 'void f(void)'. call :: Name -> Atom () call n = action (\ _ -> n ++ "()") [] -- Call a C function in its own rule, atomically. callAtomic :: Name -> Atom () callAtomic n = atom n $ call n -- Call a C function atomically with a guard condition. callGuardedAtomic :: E Bool -> Name -> Atom () callGuardedAtomic g n = atom n (cond g >> call n) Then scheduling a collection of tasks becomes easy: -- 20 millisecond tasks. period 20 $ do callAtomic "task1" callAtomic "task2" -- 5 millisecond tasks. period 5 $ do callAtomic "task3" callAtomic "task4" -- 1 millisecond tasks. period 1 $ do callGuardedAtomic task5Ready "task5" callGuardedAtomic task6Ready "task6" I'll added these 'call' combinators in the next release of Atom.

1 0

ANNOUNCE: PCLT-0.1 and PCLT-DB-0.1
by Andrey Sisoyev 12 Dec '09

12 Dec '09

Hello, cafe! It's an honor for me to announce my first two packages, I developed in Haskell: ** http://hackage.haskell.org/package/PCLT ** http://hackage.haskell.org/package/PCLT-DB "PCLT" is an abbreviation for "Parametric Composable Localizable Templates" - in fact it should also hold Detalizable. Term "Detailizable content (message)" in this package has a following meaning: some content, representing which it is possible to regulate, in how much details it is represented. "Localizable" means "localizable in languages", which is "a message is available in multiple languages". "Composable" - it is possible to compose multiple templates into one. Conceptually, this package is a powerful extension to the well known Show class. Whenever you feel, that common Show is not enough for your needs, please consider using my PCLT. The extension is thought to be embedded in any Haskell program, which requires multilingual support, and/or where messages should be detailizable. PCLT-DB is an addon to PCLT, which enhances catalog with PostgreSQL powers. ER diagram: http://i1.fastpic.ru/big/2009/1212/f0/5b9845716e5a6984e9bc9d62a61928f0.png Both packages are well documented, has "Hello World" examples, and are selfexamples - the PCLT errors representations are available in two languages: English and Russian. Used license: LGPL. Regards, Andrey Sisoyev -- View this message in context: http://old.nabble.com/ANNOUNCE%3A-PCLT-0.1-and-PCLT-DB-0.1-tp26754004p26754… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

1 0

Will GHC finally support epoll in 2009?
by Levi Greenspan 11 Dec '09

11 Dec '09

Ticket #635 "Replace use of select() in the I/O manager with epoll/kqueue/etc." (http://hackage.haskell.org/trac/ghc/ticket/635) dates back from 2005. Now its 2009 and GHC can handle hundreds of thousands of threads, yet having more than 1024 file descriptors open is still impossible. This limitation is a real bottle neck and prevents some cool developments on server side, like scalable comet servers. Instead others (e.g. Erlang guys) post stories about how they achived 1 million comet users (cf. http://www.metabrew.com/article/a-million-user-comet-application-with-mochi… ). Hence my question - is it likely that GHC will support epoll in 2009? Cheers and happy new year! - Levi

6 11

Re: Type system speculation
by oleg＠okmij.org 11 Dec '09

11 Dec '09

Andrew Coppin wrote: > What we're really trying to do here is attach additional information to a > value - information which exists only in the type checker's head, but has no > effect on runtime behaviour (other than determining whether we *get* to > runtime). As far as I can tell, Haskell does not provide any way to take an > existing type and attach additional information to it in such a way that > code which cares about the new information can make use of it, but existing > code which doesn't care continues to work. Any comments on this one? Haskell has had the ability to attach arbitrary many pieces of (type-level) data to arbitrary types for a long time -- ever since multi-parameter type classes and functional dependencies have been introduced. Nowadays, type families accomplish the same with fewer keystrokes. One merely needs to define a type family type family Attrib n index :: * which maps the existing type n and the index to an arbitrary type. Chung-chieh Shan and I have explored the technique to annotate data types with attributes describing alignment of the corresponding data, location in ROM or RAM, etc. http://okmij.org/ftp/Haskell/types.html#ls-resources Here is a sample annotation, from http://okmij.org/ftp/Computation/resource-aware-prog/VideoRAM.hs -- A Screen on old PC type ScreenCharT = Pair AWord8 AWord8 -- attribute and char proper scrchar_attr r = afst r scrchar_char r = asnd r type ScreenT = Array N25 (Array N80 ScreenCharT) data Screen = Screen instance Property Screen APInHeap HTrue instance Property Screen APARef (ARef N8 ScreenT) instance Property Screen APReadOnly HFalse instance Property Screen APOverlayOK HTrue -- many more can be added, perhaps in other modules type SmallScreenT = Array N5 (Array N80 ScreenCharT) -- we can place the Screen area at a fixed absolute address data ScreenAbs = ScreenAbs instance Property ScreenAbs APInHeap HFalse instance Property ScreenAbs APARef (ARef N8 ScreenT) instance Property ScreenAbs APReadOnly HFalse instance Property ScreenAbs APFixedAddr HTrue If we forget to assign property APReadOnly=HFalse, an operation write_area that uses a pointer in the area raises a type error.

4 3

SmallCheck design question
by Johannes Waldmann 11 Dec '09

11 Dec '09

referring to the Serial instances in http://hackage.haskell.org/package/smallcheck : the idea is that series d gives all objects of depth <= d. depth of a term from an algebraic data type is the standard "depth" concept for trees (maximum nesting of constructors = longest path from root to node) 1. why are the tuple constructors treated differently? I'd expect depth (x,y) = succ $ max (depth x) (depth y) but the succ is missing. 2. why depth and not size (= total number of constructors)? it seems that the number of objects (trees) of given depth rises much more drastically than number of trees of given size. just wondering - J.W.

2 2