January 2005 - Libraries

Cabal hooks
by Krasimir Angelov 13 Jan '05

13 Jan '05

Hello, Guys I am trying to cabalize HSQL. There is a simple ./configure script which performs some simple checks. Now I would like to perform these checks from Setup.lhs using Cabal hooks. The hooks API looks a little bit strange for me. The preConf hooks returns (Maybe PackageDescription) which after that is merged with the basic description. The Setup.buildinfo file contains only the hooked description instead of merged one. The parser requires to have package name and version, in order to properly parse the description. I need to return the right name and version from preConf hook to satisfy this restriction. I can't do this without re-reading the original description from Setup.description. Isn't it simpler to change the hooks type to something like: PackageDescription -> IO PackageDescription where the argument is the original description and the result is the possible updated one? This avoids the need of merging and simplifies the library code. Cheers, Krasimir

4 8

RE: Codec 1.0
by Simon Marlow 12 Jan '05

12 Jan '05

On 11 January 2005 20:59, Dominic Steinitz wrote: > As an interim proposal, how about I put > > Data.LargeWord What's a LargeWord? > Data.Digest.MD5 > Data.Digest.SHA-1 That will have to be SHA1 or SHA_1. > Codec.Encryption.RSA > Codec.Encryption.RSA.EMEOAEP > Codec.Encryption.RSA.MGF > Codec.Encryption.RSA.NumberTheory > Codec.Encryption.DES > Codec.Encryption.AES > Codec.Encryption.Blowfish > Codec.Encryption.Modes > Codec.Encryption.Padding > Codec.Encryption.PKCS8 > Codec.Encryption.X509 > Codec.ASN1 > Codec.ASN1.BER > Codec.ASN1.TLV > Codec.Utils > > into a package called Crypto? Looks fine! Cheers, Simon

2 1

proposed addition to System.Directory
by Ross Paterson 12 Jan '05

12 Jan '05

I find the following generalization of copyFile useful. Perhaps it could be added to System.Directory. {- |@'copyContents' old new@ copies the contents of /old/ to /new/, creating /new/ if it does not already exist. However the parent directory of /new/ must already exist. If /old/ is a plain file, 'copyContents' is equivalent to 'copyFile'. If /old/ is a directory, its contents are recursively copied into /new/, which, if it already exists, must be a directory. -} copyContents :: FilePath -> FilePath -> IO () copyContents fromFPath toFPath = do isFile <- doesFileExist fromFPath if isFile then copyFile fromFPath toFPath else do contents <- getDirectoryContents fromFPath createDirectoryIfMissing False toFPath sequence_ [copyContents (fromFPath `joinFileName` f) (toFPath `joinFileName` f) | f <- contents, f /= "." && f /= ".."]

2 1

RE: Distribution.Compat.Error
by Simon Marlow 12 Jan '05

12 Jan '05

On 11 January 2005 17:35, Ross Paterson wrote: > To re-iterate an old suggestion: how about using a custom data type > like > > data ParseResult a = ParseFailed PError | ParseOk a > > instead of Either for parse results, thus removing the dependency > on mtl, which will help with bootstrapping. I know there is > Distribution.Compat.Error, but that defines a Monad instance for > Either, so if one uses that there'll be trouble later if some program > includes both Cabal and mtl. Go for it... I'll fix up anything that depends on it in GHC. Cheers, Simon

1 0

RE: proposed addition to System.Directory
by Simon Marlow 12 Jan '05

12 Jan '05

On 12 January 2005 10:31, Ross Paterson wrote: > I find the following generalization of copyFile useful. Perhaps it > could be added to System.Directory. > > {- |@'copyContents' old new@ copies the contents of /old/ to /new/, > creating /new/ if it does not already exist. > However the parent directory of /new/ must already exist. > If /old/ is a plain file, 'copyContents' is equivalent to 'copyFile'. > If /old/ is a directory, its contents are recursively copied into > /new/, which, if it already exists, must be a directory. > -} > copyContents :: FilePath -> FilePath -> IO () > copyContents fromFPath toFPath = do > isFile <- doesFileExist fromFPath > if isFile then > copyFile fromFPath toFPath > else do > contents <- getDirectoryContents fromFPath > createDirectoryIfMissing False toFPath > sequence_ [copyContents (fromFPath `joinFileName` f) > (toFPath `joinFileName` f) | > f <- contents, f /= "." && f /= ".."] The behaviour is different from 'cp -r', so at least to me it feels a bit unusual. However, it's more consistent with copyFile, I suppose. An example or two in the documentation wouldn't go amiss. Cheers, Simon

1 0

RE: Codec 1.0
by Simon Marlow 11 Jan '05

11 Jan '05

On 10 January 2005 21:26, Dominic Steinitz wrote: > Thanks for this. I'd forgotten about the document describing the > hierarchy. The Codec.Utils exports: > > type Octet = Word8 > msb :: Int > fromTwosComp :: Integral a => [Octet] -> a > toOctets :: Integral a => a -> a -> [Octet] > fromOctets :: Num a => a -> [Octet] -> a > i2osp :: Integral a => Int -> a -> [Octet] > > Thinking about it, i2osp should go in Codec.Encryption.RSA as it's > specific to RSA. > > I'm not clear about the rest. How about Codec.Integral for toOctets, > fromOctets and fromTwosComp? I could probably live without Octet > (although quite a few standards are defined using the term octet) but > I find myself needing msb (most significant bit) in quite a few > places. Where would that go? If these really are general codec utilities, applicable to multiple codecs, then Codec.Utils is fine. There's no point trying too hard to categorise things. > Whilst on the subject, why is BER in Network? BER is one of many > encodings for ASN.1 and use of BER is not limited to networks; it is > used heavily in cryptography, for example, in PKCS#8 and X.509. I'd > suggest Codec.ASN1.BER, Codec.ASN1.TLV for the functions that take > octets and turn them into Tags, Lengths and Values and > Codec.ASN1.ASN1 for real ASN.1 types and functions. Ok, I'll add these. But Codec.ASN1.ASN1 looks a bit strange - why not just use Codec.ASN1? > Furthermore, if I follow the hierarchy for the existing cryptography > library then I would end up with Data.Digest for MD5 and SHA-1. What > would the package name for these be? Digest? What should the package > name be for DES, AES, Blowfish and RSA be? Still crypto or Encryption? You can choose any package names you like, as long as they're unique. Package names have no relationship to module names. When Hackage is up and running, you'll easily be able to find a new unique package name (for now, just pick one). Cheers, Simon

2 1

Distribution.Compat.Error
by Ross Paterson 11 Jan '05

11 Jan '05

To re-iterate an old suggestion: how about using a custom data type like data ParseResult a = ParseFailed PError | ParseOk a instead of Either for parse results, thus removing the dependency on mtl, which will help with bootstrapping. I know there is Distribution.Compat.Error, but that defines a Monad instance for Either, so if one uses that there'll be trouble later if some program includes both Cabal and mtl.

1 0

System.IO.Error
by Ross Paterson 11 Jan '05

11 Jan '05

System.IO currently re-exports System.IO.Error, but they're really different things, and the re-export is a nuisance in practice when you import both System.IO and Control.Exception. So how about dropping this re-export (and moving it to IO)?

1 0

haddock: non-ASCII characters in comments
by Ross Paterson 11 Jan '05

11 Jan '05

It would be useful to have a portable way to markup non-ASCII characters in comments. Some possibilities: &#xhhhh; or &#dddd; (as in SGML) \xhhhh (possibly with \&, as in Haskell strings) \uhhhh (as formerly in the Haskell Report) These could be converted to Char by the lexer, so there would be no direct connection to the output format (the HTML backend renders them as &#xhhhh;).

1 0

RE: Codec 1.0
by Simon Marlow 10 Jan '05

10 Jan '05

On 09 January 2005 12:43, Dominic Steinitz wrote: > base64 encoding / decoding should probably be included in Codec.Utils > (I've seen copies of the same code all over the place) and if anyone > has the time, they are very welcome to add it. > > I'd also welcome feedback on whether this is the right place in the > hierarchy for such a package and modules. We generally try to avoid names like 'Utils', if at all possible. Sometimes you really do need a bag of miscellaneous bits though (eg. Foreign.Marshal.Utils). For base64, the hierarchy design has this in Codec.Binary.Base64: http://www.haskell.org/~simonmar/lib-hierarchy.html Cheers, Simon

2 1