- Libraries - Haskell.org

darcs patch: New function isInfixOf that searches a list for a give...
by John Goerzen 01 Sep '06

01 Sep '06

Thu Aug 31 10:15:56 CDT 2006 John Goerzen <jgoerzen(a)complete.org> * New function isInfixOf that searches a list for a given sublist Example: isInfixOf "Haskell" "I really like Haskell." -> True isInfixOf "Ial" "I really like Haskell." -> False This function was first implemented in MissingH as MissingH.List.contains

7 9

System.Posix.User is inadequate
by John Goerzen 31 Aug '06

31 Aug '06

There are several problems with this module: 1) There is no way to get all users/groups on the system (getpwent) 2) The UserEntry type does not reflect the Gecos field (pw_gecos) 3) The UserEntry type does not reflect the password field (pw_passwd) 4) The GroupEntry type does not reflect the gr_passwd field This renders is unfortunately useless for some very basic Unix tasks. Is there still time to fix this for 6.6?

2 6

darcs patch: Derive Show, Read, and Eq for UserEntry and GroupEntry
by John Goerzen 31 Aug '06

31 Aug '06

Thu Aug 31 09:50:22 CDT 2006 John Goerzen <jgoerzen(a)complete.org> * Derive Show, Read, and Eq for UserEntry and GroupEntry

1 0

darcs patch: Added support for getpwent/getgrent (and 1 more)
by John Goerzen 31 Aug '06

31 Aug '06

Wed Aug 30 08:25:50 CDT 2006 John Goerzen <jgoerzen(a)complete.org> * Added support for getpwent/getgrent Wed Aug 30 08:45:17 CDT 2006 John Goerzen <jgoerzen(a)complete.org> * Fix compilation issues with new getgrent/getpwent code

2 1

System.Posix.Signals
by Neil Mitchell 30 Aug '06

30 Aug '06

Hi, Why is System.Posix.Signals defined in base on Windows, but entirely blank, while System.Posix.Process is defined in Unix? If this is a dependancy issue, then shouldn't System.Posix.Internals.Signals be in the base, and then unix export System.Posix.Signals, which is just a reexport of this? This issue is annoying because I'm trying to at least write null stubs for the functions so I can compile a program requiring unix on Windows. It doesn't help that Windows ships a version of Signals with an entirely different interface... Thanks Neil

2 1

darcs patch: Added pw_passwd and pw_gecos fields to U... (and 3 more)
by jgoerzen＠complete.org 29 Aug '06

29 Aug '06

Tue Aug 29 13:50:51 CDT 2006 John Goerzen <jgoerzen(a)complete.org> * Added pw_passwd and pw_gecos fields to UserEntry structure System.Posix.User was missing pw_gecos and pw_passwd in UserEntry. I have added them, so now the full struct passwd is represented. Tue Aug 29 13:53:00 CDT 2006 John Goerzen <jgoerzen(a)complete.org> * Whitespace changes for better alignment in unpackUserEntry Tue Aug 29 13:55:36 CDT 2006 John Goerzen <jgoerzen(a)complete.org> * Add missing field gr_passwd to GroupEntry Tue Aug 29 13:59:32 CDT 2006 John Goerzen <jgoerzen(a)complete.org> * Added some Haddock docs for UserEntry and GroupEntry

1 0

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