August 2010 - Haskell-Cafe

Microsoft's Singularity Project and Haskell
by Vasili I. Galchin 02 Aug '10

02 Aug '10

Hello, In the latest ACM CACM is a paper on Singularity. Here also is an overview: http://lambda-the-ultimate.org/node/1081. I haven't finished the CACM paper yet but I only mention of languages like C# and F#. Singularity is predicated around providing a safe environment. IMO Haskell is even better than their languages. My $.02. Regards, Vasili

9 11

Fwd: Bug in Parsec.Token
by Derek Elkins 02 Aug '10

02 Aug '10

This is a forward of a message from March 4th. ---------- Forwarded message ---------- From: Derek Elkins <derek.a.elkins(a)gmail.com> Date: Thu, Mar 4, 2010 at 9:43 PM Subject: Re: Bug in Parsec.Token To: Don Stewart <dons(a)galois.com> Cc: Greg Fitzgerald <garious(a)gmail.com>, Antoine Latter <aslatter(a)gmail.com>, "Sittampalam, Ganesh" <ganesh.sittampalam(a)credit-suisse.com>, Ian Lynagh <igloo(a)earth.li>, libraries(a)haskell.org I'm not subscribed to libraries, so this won't go there. One of the first benchmarks against Parsec 3.0.0 was John MacFarlane's here: http://www.haskell.org/pipermail/haskell-cafe/2008-March/040258.html In it, he found Parsec 3.0.0 about 2x slower for his benchmark. I can't recreate his benchmark, but I suspect it is a variant of one he describes here:http://code.google.com/p/pandoc/wiki/Benchmarks I decided to do a similar benchmark. I used Parsec 2.1.0.1, Parsec 3.0.1, and Parsec 3.1.0. Of particular note, building all three required -only- changing which library pandoc depended on. No change to the source was necessary. All tests in pandoc's test suite passed for all versions. Doing that benchmark with a different input file, this file [http://wpcal.firetree.net/wp-content/plugins/PHP%20Markdown%201.0.1k/PHP%20…] concatenated to itself 32 times to produce a 730KB markdown file, I get the following times for the last three of four runs. Parsec 2.1.0.1 derek@derek-laptop:~/temp/pandoc-1.3/dist/build/pandoc$ time ./pandoc-2.1.0.1 --strict t.text > /dev/null real 0m9.863s user 0m7.792s sys 0m0.160s real 0m9.756s user 0m7.792s sys 0m0.132s real 0m10.123s user 0m7.976s sys 0m0.168s Parsec 3.0.1 derek@derek-laptop:~/temp/pandoc-1.3/dist/build/pandoc$ time ./pandoc-3.0.1 --strict t.text > /dev/null real 0m22.008s user 0m17.445s sys 0m0.324s real 0m21.789s user 0m17.433s sys 0m0.160s real 0m21.754s user 0m17.677s sys 0m0.168s Parsec 3.1.0 derek@derek-laptop:~/temp/pandoc-1.3/dist/build/pandoc$ time ./pandoc-3.1.0 --strict t.text > /dev/null real 0m10.708s user 0m8.201s sys 0m0.168s real 0m11.078s user 0m8.401s sys 0m0.232s real 0m10.797s user 0m8.513s sys 0m0.224s These results recreate the approximate 2x slowdown that John originally mentioned between Parsec 2.1.0.1 and Parsec 3.0. It also demonstrates that Parsec 3.1.0 is significantly faster than 3.0.1 but still a little bit slower than Parsec 2.1.0.1. On Thu, Mar 4, 2010 at 4:39 PM, Don Stewart <dons(a)galois.com> wrote: > derek.a.elkins: >> Who is going to maintain "Parsec 4"? >> >> I'm completely against this. If people absolutely must have exactly >> Parsec 2's implementation we can simply copy it into Parsec 3, and the >> "compatibility" layer, in that case, will simply -be- Parsec 2. I've >> considered this as a temporary solution for the performance issues >> just so people could move to Parsec 3 dependencies, but that should >> not be necessary now, and even then I considered it a much less than >> ideal solution. >> >> If the community wants to freeze on Parsec 2, then I have no problem >> renaming the package, otherwise I think it is both unnecessary and a >> waste of effort. >> > > The problem is the ongoing lack of confidence in Parsec 3's performance. > The new release goes some way to addressing this, but I think this has > gone unaddressed for too long. > > Can someone address the lingering concern with benchmarks against parsec 2? > > -- Don >

1 0

ANNOUNCE: parsec2 - a fork or parsec circa 2.1
by Antoine Latter 02 Aug '10

02 Aug '10

Hello, I would like to announce the parsec2 package, which is a maintained fork of the parsec library as of version 2.1.0.1. This project is for folks who would like to use the simpler interface and fewer extensions relative to parsec-3.0+, but don't want to rely on an old version of a package on hackage. Parsec is designed from scratch as an industrial-strength parser library. It is simple, safe, well documented (on the package homepage), has extensive libraries and good error messages, and is also fast. Changes relative to parsec-2.1.0.1: * Added haddocks done for parsec-3 * in Parsec.Token, sort names after accounting for case sensitivity, not before from: Greg Fitzgerald When I say that I'm maintaining the parsec2 package, that means I am accepting bugfix patches and doing work to ensure that the package builds on the current version of GHC. Patches are welcome to support building on any other Haskell implementations. Any inovations in the field of parser combinators will be happening in other venues. Documentation patches are also welcome. I'm not quite sure what to do about the fact that both parsec2 and mainline parsec provide modules of the same name. If there's motion towards using the parsec2 package, we might be able to deprecate and then retire the compatibility layer provided by parsec-3.*. Links: On Hackage: http://hackage.haskell.org/package/parsec2-1.0.0 Source repository: darcs get http://code.haskell.org/parsec2/parsec2 Report a bug: http://trac.haskell.org/parsec2/newticket Antoine

5 6

ANNOUNCE: Takusen 0.8.6
by Jason Dagit 02 Aug '10

02 Aug '10

Hello, The Takusen team would like to announce the latest release of Takusen, 0.8.6. This is primarily a bug fix and test suite enhancement release. The most notable new feature is limited support for string encodings with ODBC. The full list of changes is included at the at the end of this announcement. = Interested in Takusen development? = Takusen is looking for a new long term maintainer. I have agreed to fill the role of maintainer for now, but we are seeking an enthusiastic individual with spare time and a desire to lead Takusen development. = How to get it = This release is available on hackage: cabal update && cabal install Takusen The source code is available on code.haskell.org: darcs get http://code.haskell.org/takusen = New features = - Alistair Bayley: * Database/PostgreSQL/PGFunctions.lhs: show instance for UUID prints Word64s in hex. * Database/PostgreSQL/Enumerator.lhs: add UUID and marshaling functions. * Database/PostgreSQL/PGFunctions.lhs: add UUID and marshalling functions. * Database/ODBC/OdbcFunctions.hsc: add support for different String encodings. New functions to marshal to/from various encodings (Latin1, UTF8, UTF16), and bind/get functions changed to use these. - Daniel Corson * binary data with postgres = Bug fixes = - Alistair Bayley: * Database/ODBC/OdbcFunctions.hsc: fix bug in mkBindBufferForStorable for Nothing (null) case: pass -1 (sqlNullData) as value size. * Database/ODBC/OdbcFunctions.hsc: use sqlNullData in bindParamString Nothing case, rather than -1. A bit more descriptive. * Database/ODBC/Enumerator.lhs: store bind buffers in stmt object, so we retain reference to them for lifetime of statement. Destroy with statement (well, lose the reference). Should fix bind errors found by Jason Dagit. * Database/ODBC/Enumerator.lhs: Oracle only supports two transaction isolation levels (like Postgres). String output bind parameters have max size 8000 (we use 7999 because module OdbcFunctions adds one to the size). * Database/ODBC/OdbcFunctions.hsc: string parameters have different SQL data types when binding columns (SQL_CHAR) and parameters (SQL_VARCHAR). Oracle only supports two transaction isolation levels. * Database/PostgreSQL/PGFunctions.lhs: fix byteaUnesc and add byteaEsc. = Refactoring = - Jason Dagit: * update urls in cabal file - Alistair Bayley: * Takusen.cabal: fixed QuickCheck version spec. * Takusen.cabal: bump version to 0.8.6. * Database/ODBC/OdbcFunctions.hsc: makeUtcTimeBuffer: pass struct size as both buffer size and data size in call to mkBindBuffer. * Database/ODBC/OdbcFunctions.hsc: mkBindBufferForStorable calls mkBindBuffer (reduces duplicated code). * Database/ODBC/Enumerator.lhs: add instance for EnvInquiry to change session char encoding. * Database/ODBC/Enumerator.lhs: add comments to beginTransaction. * Database/Util.lhs: print "printArrayContents", to match function name. * Database/PostgreSQL/Enumerator.lhs: expose byteaEsc and byteaUnesc. = New tests and changes to tests = - Alistair Bayley: * Database/ODBC/Test/OdbcFunctions.lhs: added testBindDouble to test Nothing (null) case for Storable types. * Database/ODBC/Test/OdbcFunctions.lhs: split transaction isolation level tests so there is one test per level. String marshaling tests use 0x10FF40 as max unicode codepoint, because that keeps Oracle happy. Max size for String parameter buffer is 7999 (SQL Server restriction). Don't bury errors raised by tests; print, but continue. Fix fixture cleanup bug in testBindOutput (dropped wrong procedure). * Database/ODBC/Test/Enumerator.lhs: suffix xxx to bindOutput test expected value. * Database/PostgreSQL/Test/PGFunctions.lhs: tests for UUID. * Database/PostgreSQL/Test/Enumerator.lhs: round-trip test for UUID. * Database/PostgreSQL/Test/PGFunctions.lhs: test select of UUID value. * Database/ODBC/Test/OdbcFunctions.lhs: set client charset to UTF8 when postgresql. * Database/Test/Enumerator.lhs: add order-bys to tests with unions. * Database/PostgreSQL/Test/PGFunctions.lhs: add order-by to union test. * Database/ODBC/Test/Enumerator.lhs: set char encoding to UTF8. inquire InfoDbmsName already returns lowercase. * Takusen.cabal: add random to build-depends for tests. * Database/Test/Enumerator.lhs: make test fixtures more friendly to MS Access. * Database/ODBC/Test/OdbcFunctions.lhs: tests modified for MS Access (date tests), plus use new char-encoding aware functions. * Database/ODBC/Test/Enumerator.lhs: change boundary dates test to not use union. Union seems to make MS Access choke. * Database/PostgreSQL/Test/PGFunctions.lhs: add tests for bytea, including QuickCheck roundtrip. * Database/PostgreSQL/Test/Enumerator.lhs: add bytea bind and select test.

9 18

Laziness question
by michael rice 02 Aug '10

02 Aug '10

From: http://en.wikibooks.org/wiki/Haskell/Laziness Given two functions of one parameter, f and g, we say f is stricter than g if f x evaluates x to a deeper level than g x Exercises 1. Which is the stricter function? f x = length [head x] g x = length (tail x) Prelude> let f x = length [head x] Prelude> let g x = length (tail x) Prelude> f undefined 1 Prelude> g undefined *** Exception: Prelude.undefined Prelude> So, g is stricter than f? Wouldn't both functions need to evaluate x to the same level, *thunk* : *thunk* to insure listhood? f x = length [head *thunk* : *thunk*] g x = length (tail *thunk* : *thunk*) Michael

13 20

Cabal LD errors
by wren ng thornton 02 Aug '10

02 Aug '10

So I'm getting some weird linking errors from cabal-install when doing `cabal configure && cabal build` ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o But cabal doesn't quit with an error code or anything. Doing `ghc --make Data/Monoid/Ord/Argmax.hs` works just fine without warnings. Anyone know what could cause them, or how to fix it? -- Live well, ~wren

3 3

Chart package segfaults when rendering to window
by briand＠aracnet.com 01 Aug '10

01 Aug '10

Seems to be ok rendering to png files. I was wondering if anybody has been using Chart and may have seen the same thing. I'm running ghc 6.12.1 and the latest and greatest gtk2hs :-) Thanks, Brian p.s. the amplitude modulation

4 4

Anyone here from New Zealand?
by Tim Matthews 01 Aug '10

01 Aug '10

Any of the haskellers here from NZ? Are you using haskell in production, internally within your company or just outside of work in your own time? In Aus they've got hackathons<http://www.haskell.org/haskellwiki/AusHac2010>and user groups <http://www.haskell.org/haskellwiki/User_groups#Australia>. Anything even remotely similar here in New Zealand? Thanks Tim Matthews

5 5

Problem loading hxt
by David Place 01 Aug '10

01 Aug '10

Hello: I am trying to load hxt into my Haskell Platform 2010.2.0.0 on OSX. I get the following bizarre comment: David-Places-Mac-Mini:dev2 davidplace$ cabal install hxt Resolving dependencies... cabal: dependencies conflict: ghc-6.12.3 requires directory ==1.0.1.1 however directory-1.0.1.1 was excluded because ghc-6.12.3 requires directory ==1.0.1.2 I see that I have the older directory in my global package list and the newer one in my local list. Help? Thanks. David-Places-Mac-Mini:dev2 davidplace$ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.3/package.conf.d Cabal-1.8.0.6 GLUT-2.1.2.1 HTTP-4000.0.9 HUnit-1.2.2.1 OpenGL-2.2.3.0 QuickCheck-2.1.1.1 array-0.3.0.1 base-3.0.3.2 base-4.2.0.2 bin-package-db-0.0.0.0 bytestring-0.9.1.7 cgi-3001.1.7.3 containers-0.3.0.0 deepseq-1.1.0.0 directory-1.0.1.1 dph-base-0.4.0 dph-par-0.4.0 dph-prim-interface-0.4.0 dph-prim-par-0.4.0 dph-prim-seq-0.4.0 dph-seq-0.4.0 extensible-exceptions-0.1.1.1 ffi-1.0 fgl-5.4.2.3 filepath-1.1.0.4 ghc-6.12.3 ghc-binary-0.5.0.2 ghc-prim-0.2.0.0 haskell-src-1.0.1.3 haskell98-1.0.1.1 hpc-0.5.0.5 html-1.0.1.2 integer-gmp-0.2.0.1 mtl-1.1.0.2 network-2.2.1.7 old-locale-1.0.0.2 old-time-1.0.0.5 parallel-2.2.0.1 parsec-2.1.0.1 pretty-1.0.1.1 process-1.0.1.3 random-1.0.0.2 regex-base-0.93.2 regex-compat-0.93.1 regex-posix-0.94.2 rts-1.0 stm-2.1.2.1 syb-0.1.0.2 template-haskell-2.4.0.1 time-1.1.4 unix-2.4.0.2 xhtml-3000.2.0.1 zlib-0.5.2.0 /Users/davidplace/.ghc/i386-darwin-6.12.3/package.conf.d Cabal-1.8.0.6 binary-0.5.0.2 directory-1.0.1.2 fingertree-0.0.1.0 haskell98-1.0.1.1 process-1.0.1.3 random-1.0.0.2 time-1.2.0.3 uu-parsinglib-2.4.2 uu-parsinglib-2.4.4 uu-parsinglib-2.4.5 uu-parsinglib-2.5.0 uulib-0.9.12

2 1

minimizing jitter while maximizing throughput
by Claude Heiland-Allen 01 Aug '10

01 Aug '10

Greeting, Jitter vs Throughput ==================== Scenario -------- I have the following scenario: CPU with [C] cores concurrent program the 1 main thread uses OpenGL for animated visual output [W] worker threads uses FFI to lengthy numerical computations with the following desires : (J) minimize jitter : the 1 main thread needs to be responsive (T) maximize throughput: idle CPU time is a waste of time The problem is, I want both (J) and (T)! Benchmarks ---------- Some rough benchmarks from my 'production' implementation[1] where: jitter = stddev of actual period (target period = 40ms) idle = C - (real time) / (user+sys time) (cores used elsewhere) (but for example Xorg will use some time for the OpenGL output, etc) C W jitter idle 2 0 1.5ms 168% threaded RTS 2 1 1.9ms 65% " " 2 2 9.4ms 46% " " 2 3 13.3ms 37% " " For comparison, a (very) minimal GLUT program gives: 0.3ms threaded RTS 0.5ms non-threaded RTS Picking (J) over (T), then setting W=1 when C=2 gives best jitter Picking (T) over (J), then setting W=2 when C=2 gives best throughput Question -------- What is the best way to re-structure the program to have both low jitter and high throughput? Options I am considering: 1. worker threads estimate the time needed to complete each job, and don't start a job if it is likely to break the deadline (bonus points if just those worker Haskell threads running on the same OS thread as the main Haskell thread need to pause) 2. change the foreign code to break jobs into smaller pieces, for example perhaps something like: worker :: IO (IO Bool) -> IO () worker getJob = forever $ do job <- getJob whileM_ job yield -- [2] instead of worker :: IO (IO ()) -> IO () worker = forever . join 3. re-implement the foreign code in Haskell instead of C and hope that GHC makes the Haskell go as fast as GCC makes the C go 5. wait (for a long time) for a new RTS with: full pre-emption (including interrupting/resuming foreign code) user settable thread priorities (1) is "a fun challenge" (there may be PhDs awarded for less, I imagine) (2) isn't quite trivial, some scope for tuning subjob chunk size (3) is boring translation but could lead to interesting benchmarks even (especially?) if it fails to be as fast as C Which would you pick? Links ----- [1] http://hackage.haskell.org/package/mandulia [2] http://hackage.haskell.org/packages/archive/monad-loops/latest/doc/html/Con… Thanks for any insight and advice, Claude -- http://claudiusmaximus.goto10.org

1 0