January 2009 - Libraries

Main-Is not creating executable
by Alistair Bayley 21 Jan '09

21 Jan '09

I have this in Takusen.cabal: Executable miniunit_tests Main-Is: Test/MiniUnit/Main.hs Build-Depends: base, mtl Extensions: CPP CPP-Options: "-DNEW_EXCEPTION" (as well as the Library section). When it builds, the modules compile fine, but then I get: Warning: output was redirected with -o, but no output will be generated because there is no Main module. The ghc command (from setup -v build): Building executable: miniunit_tests... Creating dist\build\miniunit_tests (and its parents) Creating dist\build\miniunit_tests\miniunit_tests-tmp (and its parents) c:\ghc\ghc-6.10.1\bin\ghc.exe -o dist\build\miniunit_tests\miniunit_tests.exe -- make -hide-all-packages -no-user-package-conf -i -idist\build\miniunit_tests\min iunit_tests-tmp -i. -idist\build\autogen -Idist\build\autogen -Idist\build\miniu nit_tests\miniunit_tests-tmp -optP-DNEW_EXCEPTION -optP-include -optPdist\build\ autogen\cabal_macros.h -odir dist\build\miniunit_tests\miniunit_tests-tmp -hidir dist\build\miniunit_tests\miniunit_tests-tmp -stubdir dist\build\miniunit_tests \miniunit_tests-tmp -package QuickCheck-1.2.0.0 -package Takusen-0.8.4 -package base-4.0.0.0 -package mtl-1.1.0.2 -package old-time-1.0.0.1 -package time-1.1.2. 2 -O -XCPP .\Test/MiniUnit/Main.hs I don't see ghc flag -main-is in here. What do I need to do to get it to build the executable? Also, is there a way to get it to just build miniunit_tests.exe i.e. without rebuilding the library and another executable target? Alistair

4 4

[network] #3: Cannot call connect with a socket that is already bound.
by network 20 Jan '09

20 Jan '09

#3: Cannot call connect with a socket that is already bound. ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Originally reported here: http://hackage.haskell.org/trac/ghc/ticket/2784 ---- {{{ > import Network.Socket > sock <- socket AF_INET Datagram 0 Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.0.1 ... linking ... done. > bindSocket sock (SockAddrInet aNY_PORT iNADDR_ANY) > connect sock undefined *** Exception: user error (connect: can't peform connect on socket in status Bound) }}} Network.Socket.connect checks the !SocketStatus of the socket: {{{ if currentStatus /= NotConnected }}} From [http://www.opengroup.org/onlinepubs/000095399/functions/connect.html The Open Group Base Specifications Issue 6]: "If the socket has not already been bound to a local address, connect() shall bind it to an address which, unless the socket's address family is AF_UNIX, is an unused local address." -- Ticket URL: <http://trac.haskell.org/network/ticket/3> network <http://projects.haskell.org/network/> Networking-related facilities

1 0

Participation in Cabal / Hackage development
by Duncan Coutts 20 Jan '09

20 Jan '09

All, I just mentioned ideas for Cabal 2 but I should also like to talk about how we can go about increasing participation in the development effort. We currently have nearly 200 open tickets which include many important bugs and no shortage of good ideas for useful new features. Our limiting factor is developer time. Most of us use the Cabal / Hackage system in one way or another. Most of us are familiar with its annoyances and limitations. Unfortunately the number of people helping out has dropped rather in the past year or so. Perhaps we should run a little poll like the darcs hackers did to find out what we could do to increase participation so we can get on with building the tools that we all want, but a bit more quickly. Duncan

2 3

Re: [Haskell-cafe] Cabal dependencies
by Duncan Coutts 20 Jan '09

20 Jan '09

On Thu, 2009-01-15 at 18:38 -0500, Stephen Hicks wrote: > Hi, > > I'm having some difficulty specifying dependencies in my .cabal file > for a package I'm looking to upload to hackage soon. The difficulty > is as follows. I basically want to specify > parsec (>= 2.1 && < 3.0.0) || (> 3.0.0 && < 4) When we first introduced this kind of version range syntax we were unsure if it was too general or not. We want to be able to translate into other systems and they're typically more restrictive. Internally we can easily represent the above expression as it uses arbitrary unions and intersections. However the external parser still only allows two clauses (I think it's two). Personally I'm all for lifting that restriction. Yes it makes it a bit harder for translating into some systems but I don't see that as a real issue. If the package really does require the more complex version range then forcing the package author to lie by using a less expressive syntax does not help. We can still make the same choice at the point when we translate into native packages. Also, as it happens there is a way of getting around the restriction anyway, which makes the restriction effectively pointless. That is by listing the same dependency more than once. All the version constraints must be satisfied so you can write: build-depends: parsec >= 2.1 && < 4, parsec < 3.0.0 || > 3.0.0 (have I got that right?) So I'd be interested to get feedback on lifting the restriction and the impact that might have on translation into native packages. > The problem is that 3.0.0 as it exists on hackage is missing a > constructor that I need (namely, Postfix, in the compatibility > module). The bug was fixed and will presumably work fine if a newer > version of parsec is ever uploaded to hackage, and my package works > fine with older parsecs as well - I just want to exclude this one > version. How can I go about doing that? Try the above. > A secondary question is this - I can actually compile with version > 3.0.0 by just not using this constructor, although it does reduce the > package's functionality. I've seen flags in various .cabal files, and > presumably I could invent a flag to make it work with 3.0.0, but I'm > confused about how these flags are set. Yes, if you need compatibility with older versions of Cabal then you'd need to use a flag. If you're prepared to require Cabal-1.6 or later then you can use the cpp macro: #if MIN_VERSION_parsec(3,0,0) though of course that only gives you >= 3.0.0, you'd need more tricky combinations to get == 3.0.0, perhaps by assuming >= 3.0.1 is ok. For older Cabal versions the main option is a flag, like so: flag parsec3 ... if flag(parsec3) build-depends: parsec == 3.0.0 cpp-options: -DUSING_BAD_PARSEC else build-depends: parsec > 3.0.0 || < 3.0.0 > Specifically, cabal-install has never asked me anything about flags, > so what's the point? Or does it automatically set whichever flags > satisfy the dependencies? It tries to work out what flags to set automatically (based on the platform, the available packages and flag defaults in each package). You can override them from the command line if you want to or need to. Duncan

1 0

Copyright for readline library
by Kari Pahula 19 Jan '09

19 Jan '09

I would use readline instead of editline to build ghc6 on Debian, but the readline library package in Hackage has a problem. I downloaded version 1.0.1.0 from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline and found this in System/Console/Readline.hsc: -- Module : System.Console.Readline -- Copyright : (c) unknown I'm afraid I can't use it as it is. Is there anything I could do to help to find the correct attribution for this file?

1 1

patch: Network.URI relativeFrom documentation
by Greg Heartsfield 18 Jan '09

18 Jan '09

I tried sending this before, but it appears to have not gotten through. Attached is a small patch for the Network.URI relativeFrom docs, which I believe has an error in its example. Thanks, Greg Heartsfield

1 0

Re: Improved documentation for Bool (Was: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt)
by Benja Fallenstein 18 Jan '09

18 Jan '09

On Sun, Jan 18, 2009 at 5:48 PM, <roconnor(a)theorem.ca> wrote: > I noticed the Bool datatype isn't well documented. Since Bool is not a > common English word, I figured it could use some haddock to help clarify it > for newcomers. > > -- |The Bool datatype is named after George Boole (1815-1864). > -- The Bool type is the coproduct of the terminal object with itself. Russell, this does seem like it might be very helpful, but it might be useful to include a note about what category you are working in. People may sometimes naively assume that one is working in the category of Haskell/Hugs/GHC data types and Haskell functions, in which there are no terminal -- or initial -- objects ('undefined' and 'const undefined' are distinct maps between any two objects X and Y), or else in the similar category without lifted bottoms, in which the empty type is terminal and the unit type isn't ('undefined' and 'const ()' are both maps from any object X to the unit type). These niceties will not confuse the advanced reader, but it may help the beginner if you are more explicit. - Benja P.S. :-)

1 0

Re: ANN: leapseconds-announced-2009
by Ashley Yakeley 18 Jan '09

18 Jan '09

Bjorn Buckwalter wrote: > leapseconds-announced is a pragmatic, if imperfect, improvement over > my past practices. It provides a LeapSecondTable with all leap seconds > announced to date (hence the name). Once the IERS announces[3] another > leap second the package will need an update and all code using it a > recompile. While this precludes its use in long-running production > applications it is eminently adequate for my one-off uses or for > applications that can afford to recompile infrequently. You should consider using the tz database, which provides a leap-seconds table in the "right/UTC" timezone (and much other useful information). -- Ashley Yakeley

2 3

extralibs and the haskell-platform
by Ian Lynagh 17 Jan '09

17 Jan '09

Hi all, As the plan is for the extralibs to become part of the Haskell Platform, I think we ought to have a BTS for them. I therefore propose that we create a project on community.haskell.org for each of those that are maintained by libraries(a)haskell.org. For now that will only provide a BTS (trac), but once the GHC VCS switch has happened it would make sense to move the authoritative darcs repos to community too. The packages in question are: haskell-src html HUnit mtl network parallel stm (I've left QuickCheck off as I think that it has real maintainers again) Also, I've created a haskell-platform mailing list: http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform Currently it gets mail for any changes to the haskell-platform trac, but I think that it makes sense to send mail for all the HP package tracs there too, so you don't need to subscribe to dozens of low-traffic lists to keep on top of what's going on. If the volume becomes too high then we can move the noisier packages to their own list. For now at least, discussion should stay on libraries(a)haskell.org. Any comments/objections? Thanks Ian

2 2

An Alternative Data.List.Zipper
by Jeff Wheeler 17 Jan '09

17 Jan '09

Hi, I'm somewhat of a beginner in Haskell, so take what I say with a grain of salt, please. The ListZipper implementation seems very odd to me, and #haskell seemed to agree with me. The current package implements a Zipper with > data Zipper = Zipper ![a] ![a] which allows for empty zippers, among other things. Very strange to me. It also seems unnecessarily strict. There are also no expected typeclasses implemented, like Foldable or Traversable. I thought it would be interesting to try fixing these problems with a much cleaner design, and I'd like to share what I came up with: http://hpaste.org/14006 I'd very much appreciate some criticism of the code so that I can improve it. I'm not sure how best to provide this alternative on Hackage; should we make this merely a newer version of the old library, provide it in a conflicting package, or find a new namespace for it and provide it there? Thanks, Jeff Wheeler

2 1