- Libraries - Haskell.org

proposal: reimplement Data.Graph.Inductive.Query.Dominators
by Bertram Felgenhauer 22 Apr '08

22 Apr '08

Hi, (this is Trac ticket #2227, http://hackage.haskell.org/trac/ghc/ticket/2227) As pointed out at http://www.haskell.org/pipermail/haskell-cafe/2008-April/041739.html ff., Data.Graph.Inductive.Query.Dominators.dom is buggy. Furthermore, it's slow, so instead of submitting the quick fix from that thread, I've rewritten the module from scratch using a more efficient algorithm. The algorithm works by calculating the immediate dominators of the graph nodes first, so the patch also adds a function that returns those. It should be handy for flow graph analysis. Deadline for discussion ... is a week sufficient? That would be April 28th. regards, Bertram

3 4

Announce: bytestring 0.9.1.0
by Don Stewart 21 Apr '08

21 Apr '08

Hey all, I'm pleased to announce a new major release of bytestring, the efficient string library for Haskell, suitable for high-performance scenarios. This release is primarily an (incremental) performance improvement release, though with some notable significant improvements, along with long term test coverage and quality control changes. Highlights: * a long term performance bug with Ord instances, involving very small strings, and Data.Map has been squashed. * everything's a little faster -- shootout problems showed a 1-5% speedup just by switching to the new library. Thanks goes to the Hac4 Haskell Hackathon organisers, in Gothenburg, Sweden, where the majority of this work to create this release took place. Key changes: * Data.Map short key performance greatly improved: - 'words Map' running time: 6.310s bytestring 0.9.0.1 1.071s bytestring 0.9.1.0 * Uses cheaper unsafeDupablePerformIO for allocation. - tail recursive tight loops (fixes obscure stack overflow) * Generally faster: - Shootout sum-file: 1.218s to 1.190s - Shooout fasta: 9.210s to 8.811s * 4-5x faster small substring search (breakSubstring/findSubstring/isInfixOf). * Extensive QuickCheck coverage reporting and improvements: - http://code.haskell.org/~dons/tests/bytestring/hpc_index.html Get the code: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring Note that if you upgrade to the new bytestring release, older packages built against previous releases will still require the old bytestring package. For best results, rebuild any bytestring-depending packages against the new library only. Cheers, Don

2 1

RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Johan Tibell 19 Apr '08

19 Apr '08

Good day hackers, The Python community have been successful in standardizing an interface between web server and applications or frameworks resulting in users having more control over their web stack by being able to pick frameworks independently from web servers, and vice versa. I propose we try to do the same for Haskell. I've written half a draft for a Haskell version of Python's PEP 333 [1]. If you're interested in taking part in this effort please read through the Python spec first (as it is way more complete and you can understand this proposal better by reading it, I've skipped some important issues in my first draft) and then go read the Haskell spec [2]. I'm particularly interesting in feedback regarding: * Doing in this way won't work as it violates HTTP/CGI spec part X, Y and Z (the Python spec takes lots of things from the CGI spec including naming and semantics). * My server/framework could never provide/be run under this interface. * This interface has bad performance by design. * Using a different set of data types would work better. The spec needs to be extended to cover all the corners of HTTP. Some parts need to be motivated better. It is easier for me to motivate things if people would tell me what parts are badly motivated. Note: I'm open to a complete rewrite if needed. I'm not wedded to the current design and/or wording. In fact parts of the wording is borrowed from the Python spec. The parts with bad grammar are all mine. 1. http://www.python.org/dev/peps/pep-0333/ 2. http://www.haskell.org/haskellwiki/WebApplicationInterface -- Johan

8 12

Re: [Haskell] making inits less strict
by Don Stewart 08 Apr '08

08 Apr '08

john.tromp: > The standard definition of inits: > > inits [] = [[]] > inits (x:xs) = [[]] ++ map (x:) (inits xs) > > is unnecessarily strict, evaluating its argument > before yielding the initial [] of the result. > An improved version is: > > inits l = [] : case l of [] -> [] > (x:xs) -> map (x:) inits xs > > This allows one to define for instance > nats = map length (inits nats) > which loops for the standard definition. > Can you forward this to the libraries(a)haskell.org list, and file a proposal to replace the current definition? http://haskell.org/haskellwiki/Library_submissions We noticed this while implementing lazy bytestrings, which had a similar issue, and fixing it is cheap enough. -- Don

1 0

darcs patch: fmt cabal (and 9 more)
by gwern0＠gmail.com 07 Apr '08

07 Apr '08

Mon Apr 7 00:50:28 EDT 2008 gwern0(a)gmail.com * fmt cabal Mon Apr 7 00:50:49 EDT 2008 gwern0(a)gmail.com * .cabal: +category Mon Apr 7 00:53:00 EDT 2008 gwern0(a)gmail.com * .cabal: change homepage and links The original listed website, <http://www.haskell.org/QuickCheck/>, seems to be quite dead. I've replaced it with a link to the haskell wiki and to the old chalmers site. Mon Apr 7 00:57:49 EDT 2008 gwern0(a)gmail.com * improve README Mon Apr 7 00:59:04 EDT 2008 gwern0(a)gmail.com * .cabal: add a real description Mon Apr 7 01:00:18 EDT 2008 gwern0(a)gmail.com * .cabal: BSD4 -> BSD3 license change The 4-clause BSD includes the advertising clause, and is 4 clauses long. The provided LICENSE file doesn't seem to have an advertising clause for anyone, and seems to have only 3 clauses. Which is good, as people don't like the advertising BSD license - why it's deprecated. Mon Apr 7 01:01:46 EDT 2008 gwern0(a)gmail.com * .cabal: +Bringert to copyright Per the license file, which mentions two copyright holders. Mon Apr 7 01:05:34 EDT 2008 gwern0(a)gmail.com * -Wall Monadic.hs Mon Apr 7 11:46:44 EDT 2008 gwern0(a)gmail.com * some misc partial -Wall Mon Apr 7 11:50:03 EDT 2008 gwern0(a)gmail.com * .cabal: don't forget the examples

1 0

Data.Map.toDescList not exported?
by Evan Laforge 03 Apr '08

03 Apr '08

It's in the source, marked as being O(n), but it's not in the export list. Oversight? I'm using ghc-6.8.2. I'm using (reverse.toAscList) but I think running 'head' on that is going to be less efficient than on the real toDescList. Thanks!

1 0

Re: Takusen. PostrgeSQL inserts - are they possible ?
by Alistair Bayley 31 Mar '08

31 Mar '08

> execCommand db "INSERT INTO dmlTest.t (realVal, dblVal) VALUES (?,?)" > [newBindVal (10.1::Float), newBindVal (1023.6::Double)] > > or something like: > > dmlStatement = "INSERT INTO dmlTest.t (realVal, dblVal) VALUES (?,?)" > bindTypes = [bindType (undefined::Float), bindType (undefined::Double)] > bindParams = [bindP (10.1::Float), bindP (1023::Double)] > in > withPreparedStatement (prepareCommand "test" (sql dmlStatement) > bindTypes) $ \pstmt -> > withBoundStatement pstmt bindParams $ \bstmt -> execDML bstmt > > lead to the "Segmentation fault/access violation in generated code" crash. You are right; there are gaps in the docs for the DML operations. However, there is a note in the first section ("Usage"): - for a DML command with bind variables: cmdbind "insert into ..." [bindP ..., bindP ...] e.g. cmdbind "INSERT INTO dmlTest.t (realVal, dblVal) VALUES (?,?)" [ bindP (10.1::Float), bindP (1023::Double)] Let me know if this works for you or not. If you want to use the withPreparedStatement+withBoundStatement combo, then you need to be aware that the bound statement has already been executed when it is passed to the action that is the last argument of withBoundStatement (this seems to be a significant omission from the docs). So, you don't need to do execDML bstmt; a return () should suffice. Alistair

1 0

Character escape codes in Parsec
by Tim Chevalier 31 Mar '08

31 Mar '08

Hi all, I'm using the version of Text.ParserCombinators.Parsec.Token that ships with GHC 6.8.2. I'm trying to use the stringLiteral parser that makeTokenParser uses by default to parse strings that may contain hex ASCII escape codes of the form: \x [hex-digit] [hex-digit] For example, "\x0a" should parse to "\n". On the other hand, "\x0aE" should parse to "\nE". I don't get this behavior with Parsec, though: "\x0aE" parses to "\174". I can tell from looking at the source that a hex escape code is defined to be "\x" followed by an arbitrary-length sequence of hex digits. I think this is wrong, because in ASCII, such an escape sequence has exactly two digits. I can't exactly tell from looking at the source, but is the default token parser in Parsec supposed to be parsing ASCII strings? If so, isn't this a bug in Parsec? If not, and it's meant to be able to handle Unicode or something, I think the documentation should be clearer. I'd much welcome any enlightenment. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "and the things I'm working on are invisible to everyone"--Meg Hutchinson

2 3

[hackagedb] plugins-1.1 FTBFS
by Valery V. Vorotyntsev 30 Mar '08

30 Mar '08

Hi, `plugins-1.1.tar.gz', available at HackageDB page[1], fails to configure. The darcs version[2] installs successfully. 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/plugins 2. http://code.haskell.org/~dons/code/hs-plugins What can we do to fix .tar.gz source distribution? -- vvv

2 2

ANNOUNCE: Cabal-1.4 release candidate
by Duncan Coutts 30 Mar '08

30 Mar '08

Hi everyone, == Cabal-1.4 release candidate == The first release candidate of Cabal-1.4 is out: http://haskell.org/cabal/release/cabal-1.3.10/Cabal-1.3.10.tar.gz Please test and report bugs: http://hackage.haskell.org/trac/hackage/ The aim for the Cabal-1.4 release is to get various fixes and improvements into the hands of developers and to support a release of cabal-install. == cabal-install == A snapshot of cabal-install is available: http://haskell.org/cabal/release/cabal-install-0.4.6.tar.gz It requires the zlib and HTTP packages (both are available from hackage). Bug reports should go in the same trac as above. cabal-install is intended to be the standard command line interface to the whole Cabal/Hackage system. It replaces the "runhaskell Setup.hs" interface and a few other tools you may or may not have heard of (cabal-setup, cabal-upload, cabal-get). cabal-install is usable now and we will be making a proper release some time after the Cabal-1.4 release. == Compatibility == We have tried to preserve compatibility with all packages that worked with the Cabal-1.2.x series. That is, packages that can be built using Cabal (including custom Setup.hs scripts) but not packages that directly import and use the Cabal API. Packages that directly import and use the Cabal api will need updating. This affects packages that build distro packages for example, rpm debs etc. Currently we know of three packages on hackage where their Setup.hs scripts compile with 1.2 but fail to compile with 1.4. We expect to make one further change before the Cabal-1.4 release that will fix two of those packages. The one remaining package, Takusen, will require an update to be able to work with both Cabal-1.2.x and 1.4.x. A patch has been sent to the maintainers of Takusen. == Remaining issues == There are a couple issues we expect to fix before the Cabal-1.4.0 release: * stricter decoding of UTF-8 in .cabal files (we'll borrow the code from the utf8-string package) * compatibility with the couple Setup.hs scripts that use the function Distribution.PackageDescription.writeHookedBuildInfo There are also a few bug fixes and enhancements we think we can probably do in the 1.4.x stable series without breaking any APIs: http://hackage.haskell.org/trac/hackage/query?status=new&status=assigned& status=reopened&group=component&milestone=Cabal-1.4&order=priority == Credits == On behalf of the Cabal hackers and the community generally I'd like to thank the large number of people who have contributed patches during this development series. Previously I was rather worried that we were not getting enough contributors to fix bugs and do new feature development, but now I'm very pleased. :-) == Get involved == Of course there's still a lot to do! We have big plans for Cabal-2.0, cabal-install and the Hackage website. So if you're interested in helping out with this core infrastructure project then: * subscribe to the cabal-devel mailing list: http://www.haskell.org/mailman/listinfo/cabal-devel * grab the source: http://haskell.org/cabal/code.html * read the guide to the source code: http://hackage.haskell.org/trac/hackage/wiki/SourceGuide * take a look at our list of bugs and feature requests: http://hackage.haskell.org/trac/hackage/report/12 especially the easy tickets: http://hackage.haskell.org/trac/hackage/report/13 Duncan (wearing his Cabal release manager hat)

1 0