- Libraries - Haskell.org

Deriving instance for Foreign.C.Error.Errno (trac 2261)
by Thomas M. DuBuisson 06 May '08

06 May '08

Errno, the Haskell encapsulation of the CInt 'errno' value, should be an instance of the commonly used type classes so higher level data structures that include it aren't bothered. This change will break code that has custom instances for Errno, but this should be little (if any) code. A patch is attached to the trac ticket to derive Show and Ord while Eq remains a custom instance. One could argue that, like Eq, Show and Ord should be customized to provide a identical result for all 'invalid' errno's - any thoughts on if this is necessary and what the corner case result would be? http://hackage.haskell.org/trac/ghc/ticket/2261 Thomas P.S. Traveling soon, so I won't be responsive - sorry.

2 2

QuickCheck properties for IntSet
by David Benbennick 02 May '08

02 May '08

Here's a patch to IntSet.hs that adds many QuickCheck properties. It adds properties testing almost all of the public interface of IntSet, and also properties testing that the data type invariants are never broken. (The patch doesn't test the Data, Eq, Monoid, Read, or Typeable instances.) Also, this patch removes a helper function, foldlStrict, and replaces it with calls to Data.List.foldl'. I have two questions: 1) Is this the right way to submit patches? 2) Is there a good reason that IntSet doesn't use "deriving Eq", and instead manually implements the Eq instance?

5 21

Re: getLazyByteString network I/O Bug
by Lennart Kolmodin 02 May '08

02 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Right, so it comes down to how binary handles chunks of the ByteString that might not yet be available. We have do decide what is reasonable to handle, and what could possibly trigger an error. splitAtST is too strict in the #ifndef BYTESTRING_IN_BASE version. Why the versions differ? I don't know. Even if it did not need any more data it forces the next chunk. This is easy to fix. This solves the problem when you ask for some data which is available, but the data after that is not. As I don't fully understand the splitAtST solution I can't say which splitAtST version is buggy. Then reading the last available data would create a state ~ S B.empty lbs x where lbs is an unevaluated lazy bytestring. ~ All is well as lbs remains unevaluated Curt, this is probably the bug you ran into. However, another issue; if you run any action and ask for 0 bytes; ~ like ~ * getByteString 0, or ~ * getLazyByteString 0 and no bytes are available, it would still block. Like so: ~ runGet (getByteString 0) (...blocking lazy bytestring...) This is due to that creating the state (mkState) forces the first chunk. 152 mkState :: L.ByteString -> Int64 -> S 153 mkState l = case l of 154 L.Empty -> S B.empty L.empty 155 L.Chunk x xs -> S x xs Is it acceptable to block in this case? By making splitAtST not force its last argument, let getLazyByteString and getBytes return an empty string immediately when 0 bytes are requested, we solve the three issues. Too hackish? Would anyone like to shed some light on why splitAtST forced the last argument? Cheers, ~ Lennart Kolmodin Curt Sampson wrote: | dcoutts on #haskell suggested that a difference in behaviour | between Data.Binary's getByteString and getLazyByteString was a | bug. Basically, in my particular case I send something to the | server (or for the purposes of this test, just connect) and it | sends back a non-newline-terminated response. If I pull it from the | getContents of the handle using getByteString, it works fine; if I use | getLazyByteString, it blocks, even though it has all of the data it | needs to satisfy the request. | | BTW, I did try setting the mode of the handle to non-blocking, but it | didn't make any difference in either case. | | I've attached a small project that displays this difference; see the | README at the top level to see how to try it for yourself. | | Incidently, I'm ghc 6.8.2 on NetBSD 4, and of course using the version | of Data.Binary that's included in the project, 0.4.1. | | Also, let me know if this is about the right amount of work for a test | case for something like this. It took me about an hour to put together, | so if you didn't really need all of this, I can probably send you less | next time. | | cjs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgaDOAACgkQ4txYG4KUCuEZ3ACfYJIPl/hKYoyudojK9VX5KTBe kjMAn3jFY0XnZdT7jlOZsJ004q0y6aIo =eG2B -----END PGP SIGNATURE-----

1 0

Re: Proposal: overhaul System.Process
by Simon Marlow 30 Apr '08

30 Apr '08

Brian Brunswick wrote: > On Tue, Apr 29, 2008 at 6:14 PM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> readProcessWithExitCode >> :: FilePath -- ^ command to run >> -> [String] -- ^ any arguments >> -> String -- ^ standard input >> -> IO (ExitCode,String) -- ^ exitcode, and stdout + stderr > > Surely in this case one wants stdout in a separate String to stderr? > > If something fails in the middle of a long operation, I want just the > error, doc! Well yes, but maybe you also want to tally the stderr with the stdout, to see what was going on at the time the errors were generated (modulo buffering, of course). How about two separate versions? In which case, what should they be called? Cheers, Simon

3 2

proper cabal use?
by Daniel Gorín 29 Apr '08

29 Apr '08

Hi In the hint [1] package I need to run ghc --print-libdir at configure time and save its result. The catch is that I need to run exactly the same ghc binary that will build the package (i.e. not necessarily the one in the path). Because of this requirement I can't use a "configure" script as advised in the docs [2], can I? What I did, instead, is to write a posthook that takes the information in the LocalBuildInfo and runs the ghc configured there. The downside is that this it is not portable across Cabal versions (incidentally, if I add the requirement cabal-version: >= 1.2 && < 1.3, hackage refuses to upload the package...) So my question is, what would be the proper way to handle this? Thanks Daniel [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hint-0.2 [2] http://www.haskell.org/cabal/release/latest/doc/users-guide/ x30.html#system-dependent

2 2

Issue with package "pretty"
by David MacIver 28 Apr '08

28 Apr '08

#haskell have just helped me figure out an entertaining issue with the pretty library on hackage. I couldn't figure out the right place to file a bug report and the maintainer is listed as libraries(a)haskell.org so I'm emailing the list in the hopes that someone will know what to do about it. :-) The problem is that if you install pretty, Cabal will suddenly cease working until you recompile it. It depends on a version of pretty which gets bundled with GHC is purportedly of the same version as the one on hackage, but the two aren't binary compatible. So when it tries to use it, everything goes boom.

4 9

darcs patch: Change LICENSE from BSD4 to BSD3
by Lennart Kolmodin 26 Apr '08

26 Apr '08

Sat Apr 26 07:58:06 CEST 2008 Lennart Kolmodin <kolmodin(a)gentoo.org> * Change LICENSE from BSD4 to BSD3 Picking BSD4 over BSD3 is usually by confusion. See http://hackage.haskell.org/trac/hackage/ticket/205.

1 0

darcs patch: Re-export (>>>), (<<<) from Control.Arrow for compatab...
by Duncan Coutts 25 Apr '08

25 Apr '08

It was reported in #haskell that xmonad-contrib does not compile with ghc HEAD. We tracked it down to (>>>) no longer being exported from Control.Arrow. It is now a member of the Category superclass and defined in Control.Category but it is no longer exported from Control.Arrow. It seems that any code that does not define its own arrow instances would still be able to work unchanged if (>>>) and (<<<) were just to be re-exported from Control.Arrow. So here's a completely untested patch to do that. Duncan Fri Apr 25 10:11:13 BST 2008 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Re-export (>>>), (<<<) from Control.Arrow for compatability They're now defined in Control.Category but all existing code expects them o be exported from Control.Arrow. For example, this should unbreak xmonad-contrib.

1 0

Data.Map improvement patch
by Milan Straka 24 Apr '08

24 Apr '08

Hello, Recently I was going through the Data.Set implementation and I was taken aback by setting the parameter \delta to 4. The implementation is based on Adams' bounded trees and uses ratio \alpha=2, in which case the paper clearly states \delta must be at least 4.646 (which is written in the source file Set.hs several lines above the assignment \delta=4; Map.hs uses \delta=5). So I read that Adams' paper again and found out, that the analysis described there contains two major mistakes [it is good to read the analysis from the paper now if you want to follow, pages 26 to 31]. 1) The analysis assumes that just before the balancing rotation, the heavier subtree of the unbalanced vertex was inserted to, i.e. the balance is ``off by 1''. But when the lighter subtree is deleted from, the balance is ``off by \delta'', which is worse. When taken into account, it results in equation $\delta\le{n\over\alpha}+1$, which must hold for each positive integer n. 2) The cases of empty subtrees are not analysed. When considered, it follows that for \alpha=2 a single rotation can restore balance only when \delta<5. [tree with 1 left vertex and 5 right, delete the left one and voila...] Right now I was puzzled why both Data.Set and Data.Map implementations seem to work. *) Data.Set: The constraint from the paper \delta >= 4.646 comes from the inequality $(1/\alpha) >= {\delta(1+{1\over n})+1\over\delta^2-1}$, which must hold for each positive integer n. The worst case is n=1, which is chosen in the paper. But when using n=2, the resulting constraint is \delta>3.792. The remaining case n=1 can be solved by examining all possible situations for \alpha<=2 and \delta=4, which all reveal to be correctly balanced using a~single rotation. Also the new constraint $\delta\le{n\over\alpha}+1$ can be satisfied for \alpha=2 and \delta=4 by examining small cases separately. The thing is the inequalities from the paper do not contain the floor function. Sure, for general parameters it is difficult to handle, but for the specific parameters the results are much better when truncation is taken into account. *) Data.Map: The constraint \delta<5 for \alpha=2 is not possible to change without changing the algorithm. But it turns out that the Data.Map implementation performs the balancing rotations not when one subtree is more than \delta times heavier than the other as described in the paper, but when one subtree is at least \delta times heavier. So the Data.Map implementation behaves like the analysed implementation with \delta just a bit smaller than 5. Ok, so both 4 and 5 work for the implementation of Data.Map and Data.Set. Which one is better? This parameter affects the height of a tree. With \delta=4 the worst case is 1:4, so the height is log_{5/4}n ~ 3.1 log_2 n. With \delta=5 the height is log_{6/5}n ~ 3.8 log_2 n. In Haskell, lot of operations must copy a whole path in a tree -- so a lower tree means less time and memory needed. There are more rotations, but we have to construct new nodes anyway, so one would expect minor advantage of \delta=4 over \delta=5. It is difficult to measure these things in Haskell for me (just adding a SPECIALIZE of increasing/decreasing heap size can change order of execution time), but anyway, here are times of 50000 sequential inserts, then 800000 lookups and 50000 deletes (the source is attached for the freaks): Data.Set with \delta=4 180 300 72 Data.Set with \delta=5 208 304 76 Data.Map with \delta=4 212 328 84 Data.Map with \delta=5 256 324 88 IntSet 56 356 48 IntMap 56 360 48 So I would suggest to change "delta = 5" to "delta = 4" in the Data.Map.hs and leave "delta = 4" in the Data.Set.hs file. The darcs patch is included :) Any comments are welcome, Milan

4 4

ANNOUNCE: Galois web libraries for Haskell released
by Don Stewart 22 Apr '08

22 Apr '08

Galois, Inc. is pleased to announce the open source release of a suite of web programming libraries for Haskell! The following libraries are available, providing support for a wide range of Haskell web programming scenarios: * json JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. This library provides a validating parser and pretty printer for converting between Haskell values and JSON. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json * xml A simple, lightweight XML parser/generator. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml * utf8-string A UTF8 layer for IO and Strings. The utf8-string package provides operations for encoding UTF8 strings to Word8 lists and back, and for reading and writing UTF8 without truncation. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string * selenium Haskell bindings to communicate with a Selenium Remote Control server. This package makes it possible to use Haskell to write test scripts that exercise web applications through a web browser. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/selenium * curl libcurl is a client-side URL transfer library, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE. libcurl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, Kerberos4), file transfer resume, http proxy tunneling and more! This package provides a Haskell binding to libcurl. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl * sqlite Haskell binding to sqlite3 <http://sqlite.org/>, a light, fast database. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite * feed Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds http://hackage.haskell.org/cgi-bin/hackage-scripts/package/feed * mime Haskell support for working with MIME types. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mime Together these fill in a big chunk of the web programming stack for Haskell. Get the code! You can find all the cabalised packages on hackage.haskell.org. About: Galois <http://galois.com> researches, designs and develops high assurance technologies for security-critical systems, networks and applications. We use Haskell as a primary development tool for producing robust components for a diverse range of clients. Web-based technologies are increasingly important in this area, and we believe Haskell has a key role to play in the production of reliable, secure web software. The culture of correctness Haskell encourages is ideally suited to web programming, where issues of security, authentication, privacy and protection of resources abound. In particular, Haskell's type system makes possible strong static guarantees about access to resources, critical to building reliable web applications. We hope that the release of this suite of libraries to the community will push further the adoption of Haskell in the domain of web programming. This release brought to you by: Iavor Diatchki Trevor Elliott Sigbjorn Finne Andy Gill Eric Mertens Isaac Potoczny-Jones Don Stewart Aaron Tomb

2 4