- Libraries - Haskell.org

modules of cabal-install
by Christian Maeder 25 Feb '09

25 Feb '09

Hi, I would like to reuse the module Distribution.Client.Tar from the cabal-install package. Are you willing to split up your package? Is it worth to have single module packages? Currently, Distribution.Client.Tar depends on Distribution.Client.Utils.writeFileAtomic, but this final call could be left to the user. Maybe writeFileAtomic should be in another package, too? Trying to avoid copying source code, Christian

4 11

ANN: bug fix for regex-tdfa, version 0.97.4 (and "regex-ast")
by ChrisK 24 Feb '09

24 Feb '09

Hello, The regex-tdfa package has had a series of bug fix releases (0.97.1 and 2 and 3 and now 4). This 0.97.4 releases finishes fixing the bug that was only mostly fixed in the 0.97.1 release. An example of the fixed bug: Apply the regex pattern (BB(B?))+(B?) to the text BBBB. The "BB" in the pattern should be used twice and both "B?" should match nothing. My code grouped the "+" wrong and matched the "BB" once and then both the "B?" matched a "B". The case fixed here was not initially caught because of how I search for unknown bugs. I use "Arbitrary" from QuickCheck to generate random patterns and strings to search, and compare regex-tdfa to another POSIX engine. Because I am on OS X, I am limited by the the native POSIX libraries bugs: this bug in regex-tdfa was triggered only when the native POSIX was also buggy. But the source of most of my unit tests is AT&T research [1], and they have a "libast" with a POSIX implementation. I have adapted my regex-* wrapper packages to make a "regex-ast" Haskell interface, but the difficulties with the AT&T headers prevent me from releasing this on hackage. This "regex-ast" has given me access to a less buggy POSIX back-end, and randomized testing has led to catching the bug fixed here (as well as a few bug reports back to AT&T). So while regex-tdfa will not win many speed contests, it is the only POSIX regular expression library I have running that passes all the unit tests. [1] http://www.research.att.com/sw/download/ http://www.research.att.com/~gsf/testregex/ http://www.research.att.com/~gsf/testregex/re-interpretation.html

1 0

Re: Pickling a finite map (Binary + zlib) [was: Data.Binary poor read performance]
by Christian Maeder 24 Feb '09

24 Feb '09

Felipe Lessa wrote: > The builds seem fine, but we spot a (length xs) on the beginning. > Maybe this is the culprit? We already know the size of the map (it was > serialized), so it is just a matter of exporting > > fromDistinctAscSizedList :: Int -> [(k, a)] -> Map k a Excellent idea, what does stop you? fromDistinctAscList is already a function with a precondition that is not checked. > Too bad 'Map' is exported as an abstract data type and it's not > straighforward to test this conjecture. Any ideas? One really doesn't want to see the actual implementation (except for debugging or tuning purposes), but maybe conversions to and from a fully (and uniquely) balanced binary tree are desirable. (a basic binary tree data type is still missing on hackage). I think, equal maps should not yield different serialization results just because the internal tree structure happens to be different, but that's of course debatable. Cheers Christian Maybe the discussion should be continued on libraries(a)haskell.org?

1 0

file permissions and copying files
by Duncan Coutts 23 Feb '09

23 Feb '09

All, I have complained before about the System.Directory file permissions API, and how it relates to copyFile. Let me give an example of where the existing copyFile API is too limited. Perhaps this will help us think about what an improved API might be. The example of course is build system component of Cabal. It turns out that we actually need *three* different kinds of copyFile. The only difference in each case is the treatment of file permissions / attributes. To achieve the worst case consider a source tree that is completely read only and a user umask that makes new files not world readable. The cases are: 1. Copying files within the build tree, eg as a dummy pre-processor. In this case it should behave like "cat src > dest" and not like cp. That is, it is essential that we create the new files with default permissions and not copy the source permissions. Otherwise we would end up making read-only files which would cause problems later (especially on windows). 2. Copying source files into a temp directory to prepare a source tarball. In this case we really do want to copy file permissions. In particular we want to copy executable permissions on files like ./configure. In this case it does not matter if we also copy read-only permissions because we will only delete these files, not try to overwrite them. Also, the tarball creation code will only copy executable permissions. 3. Installing files. In this case it is essential that we specify exact permissions and ignore the umask of the installing user or the permissions of the source files. The source files could be read-only and that would mess things up on windows as we would not be able to re-install over the read-only files. We also do not want to copy permissions generally because if the umask of the user that built the files was such that they're not globally readable then installing globally (eg via sudo) will install files only readable by root. Instead we have to specify that the files are read/write by their owner and readable by everyone else (and executable for binaries). If we were to generalise from these examples we'd have some copyFile function that took an extra function to generate the permissions from a combination of the source and default permissions (or it could ignore both and use specific ones). Note that in the case where I had to set specific permissions I didn't really need full control over unix permission bits, I just wanted a couple properties. I needed executable or not, readable/writable by the file owner and readable/writable by others. Is that sufficiently abstract to map onto both Windows and Unix file permissions? The thing that works least well between unix and windows file permissions is group ownership and permissions but can these be ignored in most portable situations? So at the moment we have: data Permissions = Permissions { readable :: Bool, writable :: Bool, executable :: Bool, searchable :: Bool } The main problem with this is that it is not abstract so it looses information when we do: getPermissions src >>= setPermissions dst However suppose it was an abstract type such that this worked and had the same query functions as above. Then for setting permissions we'd also have setReadable, etc :: Permissions -> Permissions. However as I mentioned above for Cabal we'd need to distinguish setting readable/writable for the file owner vs for all other users. So how about this: data Permissions -- abstract getPermissions :: FilePath -> IO Permissions setPermissions :: FilePath -> Permissions -> IO () -- | only tells us effective permissions for the current process readable :: Permissions -> Bool writable :: Permissions -> Bool executable :: Permissions -> Bool searchable :: Permissions -> Bool setUserReadable, setOtherReadable :: Bool -> Permissions -> Permissions setUserWritable, setOtherWritable :: Bool -> Permissions -> Permissions setExecutable :: Bool -> Permissions -> Permissions setSearchable :: Bool -> Permissions -> Permissions So for Unix the mapping is: setUserReadable True/False chmod u+r / u-r setUserWritable True/False chmod u+w / u-w setOtherReadable True/False chmod go+r / go-r setOtherWritable True/False chmod go+w / go-w setExecutable True/False chmod +x / -x (for files) setSearchable True/False chmod +x / -x (for dirs) So I'm aligning group with other and not distinguishing executable/searchable for user vs others. Note also that what is set by set* is not necessarily the same as what we get back from the query functions because those take all permissions into account including group permissions and other ACLs that we cannot manipulate via this API. Comments? Duncan

2 2

Proposal for Max/Min Monoids Trac ticket 3036
by William Pearson 22 Feb '09

22 Feb '09

Here is the ticket information. Will ---------- Forwarded message ---------- From: GHC <trac(a)galois.com> Date: 2009/2/19 Subject: [GHC] #3036: Max/Min Monoids To: Cc: glasgow-haskell-bugs(a)haskell.org #3036: Max/Min Monoids -----------------------------+---------------------------------------------- Reporter: whpearson | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- A small patch to Data.Monoid to give Max a and Min a monoids for (Ord a, Bounded a) = > a. Very similar to Sum and Product. Some alternatives here for unbounded Max/Mins http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1528 My current preferred one is to not to bother and perhaps put Data.AddBounds in the main branch and people can wrap Integers in that if they want. It seems conceptually purer. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3036> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

5 5

Arch Haskell News: Feb 21 2009
by Don Stewart 21 Feb '09

21 Feb '09

http://archhaskell.wordpress.com/2009/02/21/arch-haskell-news-feb-21-2009/ Arch now has 934 Haskell packages in AUR. Packages were updated or released in the following areas this week: Concurrency Control Cryptography Data Database Devel Gui Graphics Network System Web -- Don

1 0

A typeclass for byte operations?
by Don Stewart 21 Feb '09

21 Feb '09

Hey guys, At work we have many and varied needs to do bytewise operations on Haskell data. Things like: toBigEndian rotateBytes etc. Has anyone thought about: * A "Bytes" class, like the Bits class? Providing standard operations on values treated as bytes? * An Endian class, a la fromIntegral, for flipping bytes into a particular endianness. -- Don

4 7

parsec:Text.ParserCombinators.Parsec.Token wibble
by Sigbjorn Finne 20 Feb '09

20 Feb '09

Hi, the ASCII caret escape handling in the above module's makeTokenParser isn't quite right -- off by one, and only supporting A-Z carets. Could someone with privs (and maintainership badge) commit the following tweak? foo$ darcs whatsnew hunk ./Text/ParserCombinators/Parsec/Token.hs 196 - ; code <- upper - ; return (toEnum (fromEnum code - fromEnum 'A')) + ; code <- (oneOf ['@'..'_']) <|> char '?' + ; return (if code == '?' then '\DEL' else toEnum (fromEnum code - fromEnum '@')) cheers --sigbjorn

1 0

advance warning of Cabal-1.6.0.2 and package breakages
by Duncan Coutts 18 Feb '09

18 Feb '09

All, I'll be releasing Cabal-1.6.0.2 soon. I've been testing with packages on hackage for regressions. However even with the regressions fixed there will be a small handful of packages that will break with the new release. This is because they are already incorrect it's just that this was previously hidden. All these errors get picked up now because the new Cabal version checks that header files and C libs can be found at configure time. This check is generally a great help to users. Unfortunately in the case of these packages it picks up issues that did not always previously cause build failure (though could cause failure in some configurations). So I'm sorry that these 6 package now break. They are all genuine pre-existing errors though and fixing them seems a small price to pay for a better user experience for the other 1000 packages on hackage. I'm cc'ing the maintainers of the 6 packages. There is no need to release immediately, in fact you may like to wait for the release and test against it yourself to confirm whatever fixes you make. These are the packages and their errors: digest-0.0.0.2: This lists zutil.u as an include file. This is just a spelling error. It should be zutil.h of course. This does break with ghc-6.8 using -fvia-C. The behaviour of ghc-6.10 masks this error. hopenssl-1.0: This lists <openssl/evp.h> as an include file. There is of course no such file. It should be openssl/evp.h instead. This does break with ghc-6.8 using -fvia-C. The behaviour of ghc-6.10 masks this error. libxml-0.1.1: This lists libxml/xmlIO.h as an include file. On my system at least this is found under /usr/include/libxml2 not /usr/include. The best solution here is probably to use pkg-config to find the right include dir. Cabal supports this directly via: pkgconfig-depends: libxml-2.0 Again this happens to work with ghc-6.10 because it does not really use headers when compiling, but it breaks with older ghc or non-ghc. plugins-1.4.0: This specifies Linker.h as an include file. This is from the ghc rts include files. However this file cannot be included on its own. It does not compile. It needs some other rts headers to be included first. This would have failed with ghc-6.8, only the package does not work with 6.8. It does not fail wit 6.10 because 6.10 doesn't really #include headers at all. riot-1.20080618: This specifies an include file that does not exist at configure time. It specifies a file under dist/ that would be generated by running hsc2hs. This is already incorrect, but happens to work with the default dist location and current layout. If this package were uploaded today it would be rejected. sqlite-0.4.2: This specifies a include file that is not a file, but is actually a directory. It looks like confusion. Thanks Duncan

2 4

Broken dependencies on cabal install haddock
by Dave Tapley 17 Feb '09

17 Feb '09

Hi everyone, So I just grabbed the cabal and cabal-install tarballs and got them build without trouble. I thought I'd try it out by installing haddock but I get the following rather nonsensical output: ------------------------------------------------------------------------------------------------------ dave@eliza:~$ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library dave@eliza:~$ cabal install haddock Resolving dependencies... cabal: cannot configure haddock-2.4.1. It requires ghc >=6.8.2 && <6.13 There is no available version of ghc that satisfies >=6.8.2 && <6.13 dave@eliza:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 ------------------------------------------------------------------------------------------------------ I assume I'm not alone in thinking that 6.8.2 >= 6.8.2 is true? :) Cheers, Dave

4 5