August 2006 - Libraries

status report of HaskellNet
by Jun Mukai 25 Aug '06

25 Aug '06

Dear all, HaskellNet is develped under GSoC program, and I'd like to report the current status of HaskellNet. HaskellNet will be a collection library for networking. Now, it contains, - SMTP - POP3 - IMAP - HTTP - (FTP) - URI - Mime parser and, I wrote a Stream like type class of ByteString. I also wrote the example code to connect these libraries with hsgnutls. Because FTP client is came from missingh, it is licensed under LGPL (Thanks to John Goerzen). Others includeing HTTP (came from Bjorn Bringert's code) are licensed under BSD3. You can obtain the codes from http://darcs.haskell.org/SoC/haskellnet (add .lgpl to get with FTP client). The period of SoC will end soon, but HaskellNet is now under development. Although the current codes have (maybe) no problems, they can not be tested fully. In addition to it, I want to add other protocols and other ideas. Actually, There are discussions between me and Alexander Jacobson about importing Protocol.DNS from HAppS. But, I did not have the time to do it (Although it can be done shortly). I mean, I'd like to keep the development of HaskellNet. Any comments are welcome. Best Regards, Jun Mukai mukai(a)jmuk.org

5 4

Re: Packages in GHC 6.6
by Krasimir Angelov 25 Aug '06

25 Aug '06

I wrote simple tool that I am using to build MSI installer for Visual Haskell. It will not be so hard to extend it to support Cabal. After that it will be easy to prepare an installer for GHC with optional libraries. Don't expect it to be ready for 6.6 release! Cheers, Krasimir On 8/22/06, Jason Dagit <dagit(a)eecs.oregonstate.edu> wrote: > [snipped] > For the windows installer, I imagine this working something like the > cygwin or ms office installer. There could be a screen listing all > the libraries and the installer itself comes in two flavors, either > contains only the minimum (and uses the network to grab any > additional) or the installer contains everything and lets the user > select which packages to install (defaulting to everything).

2 2

Packages in GHC 6.6
by Simon Marlow 24 Aug '06

24 Aug '06

Here is what I propose to do regarding the libraries we ship with GHC 6.6. Comments are appreciated, since we need to finalise this story before the release candidate at the end of this week. For a while we have had the goal of devolving as many of the libraries that ship with GHC as possible. With Cabal, this is now possible: you can download GHC and then install 3rd-party packages with little hassle, or upgrade libraries that came with your GHC installation. So the days of the monolithic GHC+libraries installations should perhaps come to an end. On the other hand, it's often quite useful to be able to install a single distribution and get a comprehensive set of libraries. The folks who package GHC for the deeply package-based OSs like Debian, Gentoo and *BSD would like GHC to come with a minimal set of libraries and install the others as separate packages. Another consideration is that it's useful for our nightly builds to build as many libraries as possible, so we can help catch bitrot. However, the default GHC build now takes a very long time mostly due to the huge set of libraries, and most people building GHC don't need to build eg. OpenGL by default. What's more, the maintainers of many of these libraries would like to be able to make releases independently of GHC. So here's what I propose: - A "GHC source tree" will contain a core set of packages. This is what you will get if you download ghc-6.6-src.tar.bz2, or do "sh darcs-all get" in a darcs repo. The core packages are: base, haskell98, template-haskell, readline, stm, Cabal, unix, Win32 plus hopefully regex-base and regex-posix if I integrate them this week. These are the packages required to bootstrap GHC, or those with deep GHC dependencies (template-haskell & stm). - The core packages will have a stable API across patchlevel releases of GHC (perhaps with the exception of Cabal). We will fork the darcs repos of the core packages where necessary. - A source tree can optionally be populated with more packages, which will be included in the build as normal. At the moment, the only packages you can add in this way are: ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi, fgl, haskell-src, html, mtl, network, parsec, time, xhtml because we're still using GHC's build system to build packages rather than Cabal. When we switch to using Cabal to build packages inside a GHC build, then it will be possible to populate the tree with any Cabal package. Possibly we could also distribution an "extra libs" source bundle containing these packages. - We will continue to build all these packages in the nightly builds. (but perhaps build failures in optional packages should not break the whole build). - darcs-all will have an option to grab the optional packages (all the packages in the list above). - Gentoo, Debian etc. will include only the core packages with GHC, the others will become separate entities. - We will continue to bundle the .tar.bz2 binary distributions, and the Windows installer, with all the optional packages. Perhaps there could also be minimal installers containing just the core packages. - We may have to change the set of core packages in the future, if GHC accumulates more dependencies for example. Any comments, or suggestions? Cheers, Simon

4 9

Cabal: outstanding copyFile bug?
by Frederik Eaton 23 Aug '06

23 Aug '06

Hi, I tried installing Cabal-1.1.4, but a bug from a long time ago is still present. Is it the case that if the new Cabal is in my package database, then it will be used? $ ghc-pkg list /home/frederik/arch/i386//lib/ghc-6.4.2/package.conf: Cabal-1.1.4, GLUT-2.0, HGL-3.1, HUnit-1.1, OpenGL-2.0, QuickCheck-1.0, X11-1.1, base-1.0, (concurrent-1.0), (data-1.0), fgl-5.2, haskell-src-1.0, haskell98-1.0, hsql-1.7, hsql-mysql-1.7, (hssource-1.0), (lang-1.0), mtl-1.0, (net-1.0), network-1.0, parsec-1.0, (posix-1.0), readline-1.0, rts-1.0, stm-1.0, template-haskell-1.0, (text-1.0), unix-1.0, (util-1.0) /home/frederik/.ghc/i386-linux-6.4.2/package.conf: Futility-0.1.8, GSL-0.5 The bug occurs when there is an existing file with the same path as one which Cabal is trying to install - rather than unlinking and creating a new file, it seems that Cabal tries to open the existing file and write to it. ... Skipping Main ( programs/move-spool.hs, dist/build/move-spool/move-spool-tmp/Main.o ) dist/build/move-spool/move-spool is up to date, linking not required. Installing: /home/frederik/lib/Futility-0.1.8/ghc-6.4.2 & /home/frederik/bin Futility-0.1.8... *** Exception: /home/frederik/bin/fssh: copyFile: resource busy (Text file busy) Regards, Frederik -- http://ofb.net/~frederik/

4 10

Graphics.SOE.Gtk
by Duncan Coutts 23 Aug '06

23 Aug '06

Due to popular demand, the new SOE implementation based on Gtk2Hs is now available separately: http://haskell.org/~duncan/soegtk-0.9.10.tar.gz http://haskell.org/~duncan/soegtk-0.9.10.zip or darcs get http://haskell.org/~duncan/soegtk/ It works with the latest released version of Gtk2Hs, ie version 0.9.10 It works at least on Linux and Windows. It's packaged with Cabal. The rendering quality is better than the original HGL version. Here's a side-by-side comparison: http://haskell.org/~duncan/gtk2hs/SOE-cairo.png and it works with GHC on Windows, which the original doesn't. Sadly it doesn't work with Hugs98 (but I hear that the HGL version does work with Hugs98). There may be some slight differences in the semantics from the original. Please test it with any SOE examples you've got. If you find any mismatches, then report them as bugs here: http://hackage.haskell.org/trac/gtk2hs/newticket Enjoy. Duncan

1 0

ThreadId gripe
by Frederik Eaton 22 Aug '06

22 Aug '06

Hi, The 'Show' instance for ThreadId produces stuff like "ThreadId 1" - not very concise. Is there an simple way to turn it into an Int or Integer so I can call 'show' on that? Usually ThreadId's are turned into strings for the purpose of logging, in which case one really only wants the numeric part. Best, Frederik -- http://ofb.net/~frederik/

2 2

Building cabal with cabal fails?
by Neil Mitchell 22 Aug '06

22 Aug '06

Hi, Using GHC 6.4.2, in prepration for some cabal hacking, I decided to download Cabal from darcs and install it. darcs get http://darcs.haskell.org/packages/Cabal --partial cd Cabal runhaskell Setup configure And I get the error: ./Distribution/Simple.hs:61:1: lexical error Should this work? If not, what should I be doing. Thanks Neil

6 9

Cabal patch: Add setup haddock --hoogle option
by Neil Mitchell 22 Aug '06

22 Aug '06

Hi, The attached patch adds support for the --hoogle option to the haddock target. Tested on the base package, now running: runhaskell Setup haddock --hoogle Gives the file base-2.0.txt which can then be fed into Hoogle properly. Anything wrong with it? If not, can it be applied? Thanks Neil

2 1

what's in a package name?
by Andrew Pimlott 22 Aug '06

22 Aug '06

I just tried creating my first package with Cabal, and chose a package version, "0", that obeys the rules documented by Cabal: "a sequence of one or more integers separated by dots"[1]. But at the end of the build, I got "ghc-pkg: ambiguous package identifier: foo-0". (I am using ghc 6.4.2.) Simon Marlow already commented on this silly problem[2], but it appears it was never resolved. Can someone just decide on the systax of a package identifier? Cabal's documented rules seem sane to me: A package is identified by a globally-unique package name, which consists of one or more alphanumeric words separated by hyphens. To avoid ambiguity, each of these words should contain at least one letter.... A particular version of the package is distinguished by a version number, consisting of a sequence of one or more integers separated by dots. These can be combined to form a single text string called the package ID, using a hyphen to separate the name from the version, e.g. “HUnit-1.1”. Andrew [1] http://www.haskell.org/ghc/docs/latest/html/Cabal/ [2] http://www.haskell.org/pipermail/glasgow-haskell-users/2005-February/007801…

2 1

Replacing Network.CGI with NewCGI
by Bjorn Bringert 22 Aug '06

22 Aug '06

Any users of Network.CGI here? I would like to propose replacing the current Network.CGI module with what is now known as Network.NewCGI [2]. This has been mentioned briefly before [1]. The new module is backwards compatible with the old one (except for the export of Text.Html.Html, which is now Text.XHtml.Html). Here is what I would like to do: - Remove Network.CGI from the network package. - Change the name of Network.NewCGI to Network.CGI - Add the cgi package to http://darcs.haskell.org/packages/ - Add the xhtml package [3] to http://darcs.haskell.org/packages/ This is needed since the cgi package uses it to generate error pages. Any comments, suggestions, or objections? Here is a summary of the features of NewCGI: - Access to CGI parameters (e.g. form input) from both GET and POST requests. - Access to CGI environment variables. - Ability to set arbitrary response headers. - Support for HTTP cookies. - An efficient implementation of multipart/form-data using Data.ByteString. This allows for efficient handling of file uploads. - Wrapper functions for compatibility with the existing Network.CGI module. - A CGI monad transformer. - Basic exception handling and logging. - Low-level run functions that allow using NewCGI programs with protocols other than CGI, for example FastCGI [4]. /Björn [1] http://www.haskell.org/pipermail/libraries/2006-May/005391.html [2] http://www.cs.chalmers.se/~bringert/darcs/haskell-cgi/doc/ [3] http://www.cs.chalmers.se/~bringert/darcs/haskell-xhtml/doc/ [4] http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/doc/

3 4