June 2008 - Libraries

Broken packages on hackage
by Don Stewart 19 Jun '08

19 Jun '08

Just did a full run over hackage, building packages with ghc 6.8.2, bytestring 0.9.0.1 and cabal 1.4.1.. Several hundred packages built fine. The majority are relatively easy to fix, if the upstream authors can be contacted. The following could be marked broken, if we could do that. Easy: Doesn't support small-base: AGI libxml newbinary openafp StategyLib Catch classify collections compression dataenc derangement hogg hsc2hs 2006 hslogger hsns hsql lambdaFeed metaplug mime-string pointfree sat soegtk sparsecheck special-functors (needs base<2 !) suffixtree th-lift torrent udcode More work: Broken: BerkleyDB -- missing extra-libs at least dbus -- various things. encode -- type errors flippi -- depends on unreleased cgi version finance-treasury -- needs new hxt-filter (author has patch) HsPerl5-0.0.4 -- cc1: error: unrecognized command line option "-Wl" HsSVN -- missing extra-libraries: svn Monadius -- missing: extra-libraries: glut shu-thing -- missing: extra-libraries: glut postgresql -- Too many parameters for class `MonadDatabase' probabilitymonads -- Illegal instance declaration sdl -- gcc: unrecognized option '-rpath' baskell -- missing modules bot -- Duplciate Instance cabal-setup -- type error cabal-tests -- Could not find module `Tests' cabalrpmdeps -- cabal type error clustertools -- missing constructors debian -- cabal type error dephhd -- type error hs-pgms -- missing modules network-rpca -- type error parsely -- missing -XFunctionalDependencies ports -- cpp errro postmaster -- (.text+0x1442): undefined reference to `EVP_mdc2' ? reify -- linker error reifyC roguestar -- Could not find module `Keymaps.CommonKeymap' slackbuild -- cabal innards lax -- cabal innards lhs2tex -- cabal innards rss -- needs haxml 1.3..<1.4 scenegraph -- source for Graphics.SceneGraph.SimpleViewport shell-pipe -- `GHC.Handle' does not export `openFd' srcinst -- module Dpkg missing state -- Setup: COPYRIGHT: copyFile: does not exist storablevector -- QC arbitrary missing Control.Monad.Instances truelevel -- Could not find module `TrueLevelArgs' type-int -- Could not find module `Data.Type.Sign' GHC error: WURFL --stack overflow on large file cedict -- stack oflow on 32k large list cpuid -- Error: suffix or operands invalid for `test' Depends on something hidden: HDBC-postgresql-1.1.4.0, Cabal version: >=1.2 && <1.3 Takusen cabal-upload regex-dfa regex-parsec regex-pcre regex-tdfa -- Don

7 12

haxml
by Don Stewart 17 Jun '08

17 Jun '08

The haxml version of hackage.haskell.org relied on the deprecated function 'ByteString.join' which has been replaced with 'ByteString.intercalate' since the last release. This means haxml doesn't build with bytestring 0.9.1.0, which some people might have updated to. Malcolm, what should we do ? I can reintroduce 'join' and leave it deprecated for another year, or is there a new haxml release on the horizon? A non-working haxml affects an awful lot of hackage. -- Don

3 5

Re: [Haskell-cafe] 1/0
by Henning Thielemann 17 Jun '08

17 Jun '08

On Mon, 16 Jun 2008, Dan Doel wrote: > On Monday 16 June 2008, Evan Laforge wrote: > >> (huge negative number) >> >> Ok, so integral types don't have that exceptional value. Shouldn't >> trying to convert NaN or Infinity to an Integral throw something? Is >> it a performance thing? I'd think if you're converting to Integer you >> don't really need hardware level performance anyway, so a couple of >> checks wouldn't kill anyone. > > This is a (known by some) bug of sorts in the various floating point -> > integral transformations (which ultimately boil down to decodeFloat or > something like that at some point). It apparently doesn't know about the > various exceptional values in the IEEE representation, so it just treats the > representation like any other value. Infinity and NaN look like various huge > numbers if you interpret them like any other value, so that's what you get > out of round/ceiling/floor/etc. > > It's not ideal, but I guess no one's bothered to fix it. Might be something to > bring up on the libraries mailing list. This could be combined with improving performance: http://hackage.haskell.org/trac/ghc/ticket/2281 http://hackage.haskell.org/trac/ghc/ticket/2271 http://hackage.haskell.org/trac/ghc/ticket/1434

1 0

HTTP(S) ?
by Johannes Waldmann 16 Jun '08

16 Jun '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 can the HTTP module handle https connections? would this then work with haxr: remote "https://foo.bar/cgi-bin/server.cgi" ... best regards, J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVgyHDqiTJ5Q4dm8RAv6NAKChUNuQWdW1Ej8YY3+/GeqR+b3TiACcCxha hIFujlBcmWGxiplXo519USo= =gO8x -----END PGP SIGNATURE-----

2 1

Maybe-summary was: Re: [Haskell-cafe] Re: [Haskell] ANN: random-access-list-0.1
by Isaac Dupree 13 Jun '08

13 Jun '08

Claus Reinke wrote: >> To summarize: Monad isn't the proper abstraction for failable/Maybe. >> Maybe is an algebraic data type that *exactly* represents the spirit >> of what you're trying to do: e.g. Conor McBride said: "Maybe is the >> most general abstraction. Requiring (>>=), or even (<*>) seems >> excessive. What we need is "any f with zero and return", so why not >> pick the canonical, initial, inductively defined such thing?" In this >> case the typeclass adds no generality to the function's behaviour >> (Maybe can be trivially converted to any other type, with a combinator >> even). And the confusion that results, when the function is almost >> always used at type Maybe anyway. If you want to read the whole >> discussion... if you haven't been subscribed to libraries(a)haskell.org >> , it's archived: >> http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9082 > > Thanks for the summary. I had been wondering about this > change of mood, and I disagree with the suggestion that > Maybe Nothing is the right replacement for Monad fail. > Whether fail should be in Monad, or whether we really want MonadZero, > MonadPlus, MonadError, or something else entirely has been open for > discussion, but it is easily shown > that Maybe is not the most general abstraction - it loses information > wrt to (Either String), for instance: > > Prelude> let {f [] = fail "empty"; f [_] = fail "singleton"; f l = > return l } okay, I see, it's just that most partial functions in Data.* / container libraries don't really have multiple failure modes that need distinguishing. You could say, in a type/information-theoretic mindset, that even your "f [_]" above loses information because it doesn't vary based on the _ (and so it isn't reversible) (and this is very common and normal especially for error messages, but there's a large design space for places where they're needed, depending on whether a machine needs to understand the message, etc.) I think we didn't conclude much about e.g. parser-library return types, because we (thankfully) weren't trying to. -Isaac

2 1

darcs patch: Re: Readline readHistory & writeHistory API broken
by Judah Jacobson 12 Jun '08

12 Jun '08

On Wed, Jun 11, 2008 at 5:04 AM, Krasimir Angelov <kr.angelov(a)gmail.com> wrote: > Just fixing the comments is also fine for me. I personally use another > file name. > > On 6/11/08, Ian Lynagh <igloo(a)earth.li> wrote: >> On Sun, Jun 08, 2008 at 05:30:34PM +0200, Krasimir Angelov wrote: >> > >> > Note the comments "(if null, write ~/.history)"! This is supported in >> > the original C API but in Haskell the filepath cannot be null. In the >> > best case it can be empty string. Either the type signatures have to >> > be changed to accept (Maybe FilePath) or the comments have to be >> > changed because the Haskell binding currently doesn't support this >> > functionality. >> >> If writing to ~/.history is useful then Maybe FilePath makes sense to >> me, as ~/.history is a bit fiddly to work out yourself. >> >> However, it doesn't sound that useful to me, as then all applications >> would trample over each other. >> >> If you want to propose that it uses Maybe FilePath then you'll need to >> follow http://www.haskell.org/haskellwiki/Library_submissions; otherwise >> I'll just fix the comments. >> I agree that just fixing the comments is fine. Ian, it looks like the editline library also has this problem. Can you please apply the attached patch (or its equivalent)? Wed Jun 11 11:16:24 PDT 2008 Judah Jacobson <judah.jacobson(a)gmail.com> * Remove erroneous comment from readHistory and writeHistory. M ./System/Console/Editline/Readline.hsc -2 +2 Thanks, -Judah

2 2

installing non-haskell binaries with cabal
by Misha Aizatulin 12 Jun '08

12 Jun '08

hello, I would like to distribute a shell script as part of my haskell project. How can I tell cabal to install the script as an executable? Cheers, Misha

7 11

haddock: record types with partially exported fields
by Misha Aizatulin 11 Jun '08

11 Jun '08

hello, attached (M1) is an example of a situation, where haddock hides all fields of a record, just because one field is hidden. The result is that the other field is not shown in the documentation as well, even though it is exported. As an example for why hiding certain fields of a record might make sense, consider M2. There we export two functions for decomposing T: f and g, whereas f is a class function that can be used for other datatypes as well, and g is a function specific to T. The ugly fT function is hidden from the user. I'd wish myself a haddock output in which T would be shown in record style, but there would be a blank instead of fT or maybe something like "<hidden>". Cheers, Misha P.S. What's the right place to talk about haddock by the way?

5 9

Readline readHistory & writeHistory API broken
by Krasimir Angelov 11 Jun '08

11 Jun '08

The current readHistory and writeHistory bindings are defined as: -- |Read in a history file. Returns 'False' on failure -- (for example, if the file does not exist). readHistory :: FilePath -- ^ The file to read (if null, read ~\/.history) -> IO Bool readHistory fp = do ok <- withCString fp read_history return (ok==0) foreign import ccall unsafe read_history :: Ptr CChar -> IO CInt -- |Write out a history file. Returns 'False' if there was a problem writing the file. writeHistory :: FilePath -- ^ The file to write (if null, write ~\/.history) -> IO Bool writeHistory fp = do ok <- withCString fp write_history return (ok==0) foreign import ccall unsafe write_history :: Ptr CChar -> IO CInt Note the comments "(if null, write ~/.history)"! This is supported in the original C API but in Haskell the filepath cannot be null. In the best case it can be empty string. Either the type signatures have to be changed to accept (Maybe FilePath) or the comments have to be changed because the Haskell binding currently doesn't support this functionality. Comments? I hope that this will not start another endless discussion. Regards, Krasimir

2 2

Feature request: more transparency for Data.Graph.Inductive.NodeMap
by Misha Aizatulin 11 Jun '08

11 Jun '08

hello, would it be possible to add functions to NodeMap for inspecting the contents of the map? I would be particularly interested in a function like toList :: NodeMap a -> [LNode a] If I use a node map m to construct a graph g, then of course (labNodes g) would achieve the same as (toList m), but if I later transform the labels of the graph, say using nmap, then I cannot do it anymore - the connection between old label values and nodes is still a valuable piece of information, but I cannot access it. Cheers, Misha

4 5