February 2009 - Libraries

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 23 Feb '09

23 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 22 Feb '09

22 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 22 Feb '09

22 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 21 Feb '09

21 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 19 Feb '09

19 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 18 Feb '09

18 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

Crypto Package Ownership
by Dominic Steinitz 16 Feb '09

16 Feb '09

Creighton Hogg has very kindly volunteered to take over its maintenance. The code base is kept on code.haskell.org: > dom@nun:/srv/code/crypto$ ls -ltr > total 92 > -rw-rw-r-- 1 dom crypto-p 6711 Dec 6 09:29 SymmetricTest.hs > -rw-rw-r-- 1 dom crypto-p 79 Dec 6 09:29 Setup.hs > -rw-rw-r-- 1 dom crypto-p 8779 Dec 6 09:29 SHA1Test.hs > -rw-rw-r-- 1 dom crypto-p 4910 Dec 6 09:29 RSATest.hs > -rw-rw-r-- 1 dom crypto-p 2245 Dec 6 09:29 QuickTest.hs > -rw-rw-r-- 1 dom crypto-p 4918 Dec 6 09:29 HMACTest.hs > drwxrwsr-x 3 dom crypto-p 4096 Dec 6 09:29 Data > -rw-rw-r-- 1 dom crypto-p 1975 Dec 6 09:29 CryptoHomePage.html~ > drwxrwsr-x 5 dom crypto-p 4096 Dec 6 09:35 oldrepo > drwxrwsr-x 2 dom crypto-p 4096 Jan 4 03:56 doc > -rw-rw-r-- 1 dom crypto-p 2534 Jan 4 03:56 WordListTest.hs > drwxrwsr-x 5 dom crypto-p 4096 Jan 4 03:56 Codec > -rw-rw-r-- 1 dom crypto-p 3644 Jan 4 03:58 crypto.cabal > -rw-rw-r-- 1 dom crypto-p 10839 Jan 4 03:58 ReadMe.tex > drwxrwsr-x 6 dom crypto-p 4096 Jan 4 03:58 _darcs > -rw-rw-r-- 1 dom crypto-p 1973 Jan 4 04:01 CryptoHomePage.html Is there a way of changing the owner? Creighton's account is wchogg. Many thanks, Dominic.

2 2

Control.Concurrent.MVar documentation broken
by David Menendez 13 Feb '09

13 Feb '09

I was just looking at <http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurre…> and I noticed that the documentation for withMVar, modifyMVar, and modifyMVar_ is missing. This appears to be caused by the INLINE pragmas. I've done some experiments, and I've found that Haddock 2.4.1 will not display the documentation if an INLINE, NOINLINE, or SPECIALIZE pragma appears between the documentation and the signature. I don't know whether this is a bug in Haddock or Control.Concurrent.MVar. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

2 1

Binary: Put -> Builder
by Henning Thielemann 13 Feb '09

13 Feb '09

Is there a way to get the underlying Builder of a 'put' of a Binary instance? How does the Char instance of Binary serialize?

7 14