- Libraries - Haskell.org

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

RE: stuff to add to FilePath or System.directory?
by Simon Marlow 10 Jan '05

10 Jan '05

On 10 January 2005 09:03, Krasimir Angelov wrote: > I would like to have these functions in > System.Directory. Just some notes: > > - createDirectoryIfNotExists seems to be better > name for createIfNotExists. This makes clear that the > function creates directory. Since createIfNotExists > creates the parents only it is explicitly specified > createDirectoryAndParents doesn't sound very well for > me. I suggest createDirectoryIfMissing, or ensureDirectoryExists as more grammatically-pleasing alternatives. Cheers, Simon

1 0

stuff to add to FilePath or System.directory?
by Isaac Jones 10 Jan '05

10 Jan '05

Here's some stuff that I have in the cabal Utils module that might be useful in System.FilePath or System.Directory... What would folks think of adding them? I find createIfNotExists to be especially useful, though maybe it should be createDirectoryAndParents or something. peace, isaac ------------------------------------------------------------ module PathStuff (createIfNotExists, currentDir, removeFileRecursive) where import Control.Monad (unless, liftM, mapM) import Data.Maybe (Maybe, catMaybes) import System.IO.Error (try) import System.FilePath (pathParents) import System.Directory (getDirectoryContents, removeDirectory, setCurrentDirectory, getCurrentDirectory, doesDirectoryExist, removeFile, createDirectory) createIfNotExists :: Bool -- ^Create its parents too? -> FilePath -- ^The path to the directory you want to make -> IO () createIfNotExists parents file = do b <- doesDirectoryExist file case (b,parents, file) of (_, _, "") -> return () (True, _, _) -> return () (_, True, _) -> createDirectoryParents file (_, False, _) -> createDirectory file -- |like mkdir -p. Create this directory and its parents createDirectoryParents :: FilePath -> IO() createDirectoryParents file = mapM_ (createIfNotExists False) (tail (pathParents file)) -- |The path name that represents the current directory. May be -- system-specific. In Unix, it's "." FIX: What about other arches? currentDir :: FilePath currentDir = "." -- |Probably follows symlinks, be careful. removeFileRecursive :: FilePath -> IO () removeFileRecursive startLoc = do cont' <- getDirectoryContents startLoc let cont = filter (\x -> x /= "." && x /= "..") cont' curDir <- getCurrentDirectory setCurrentDirectory startLoc dirs <- removeFiles cont mapM removeFileRecursive dirs setCurrentDirectory curDir removeDirectory startLoc -- |Remove a list of files; if it encounters a directory, it doesn't -- remove it, but returns it. Throws everything that removeFile -- throws unless the file is a directory. removeFiles :: [FilePath] -- ^Files and directories to remove -> IO [FilePath] {- ^The ones we were unable to remove because they were of an inappropriate type (directory) removeFiles -} removeFiles files = liftM catMaybes (mapM rm' files) where rm' :: FilePath -> IO (Maybe FilePath) rm' f = do temp <- try (removeFile f) case temp of Left e -> do isDir <- doesDirectoryExist f -- If f is not a directory, re-throw the error unless isDir $ ioError e return (Just f) Right _ -> return Nothing

2 1

Cabal, installing it
by David Owen 09 Jan '05

09 Jan '05

Hello all, I have a question about installing the Cabal tool. After downloading and extracting it to a folder I seem to be unable to install it correctly. I moved into the cabal folder which contains a Makefile, and typed 'make'. A longish compilation/installion took place and so I hoped that all was well. However when including it as a package when compiling with GHC (6.2.2) it simply says: ghc-6.2.2: unknown package name: Cabal The command I used to compile was ghc -package Cabal Setup.lhs -o setup So it seems Cabal hasn't actually installed properly. I'm quite new to Linux (I'm using SuSE 9.0) so I hope that there might be a simple answer. I would like to install Cabal so that I can use Warrick Gray's new versions of the HTTP modules. Any answers will be gratefully received. Thanks Dave Owen

2 1

Cabal, installing it
by David Owen 09 Jan '05

09 Jan '05

Hello all, I have a question about installing the Cabal tool. After downloading and extracting it to a folder I seem to be unable to install it correctly. I moved into the cabal folder which contains a Makefile, and typed 'make'. A longish compilation/installion took place and so I hoped that all was well. However when including it as a package when compiling with GHC (6.2.2) it simply says: ghc-6.2.2: unknown package name: Cabal The command I used to compile was ghc -package Cabal Setup.lhs -o setup So it seems Cabal hasn't actually installed properly. I'm quite new to Linux (I'm using SuSE 9.0) so I hope that there might be a simple answer. I would like to install Cabal so that I can use Warrick Gray's new versions of the HTTP modules. Any answers will be gratefully received. Thanks Dave Owen

1 0

Re: cvs commit: fptools/libraries/Cabal/Distribution GetOpt.hs Setup.hs Simple.hs
by Sven Panne 09 Jan '05

09 Jan '05

In the cvs-libraries list Isaac Jones wrote: > ijones 2005/01/05 23:42:11 PST > > Modified files: > libraries/Cabal/Distribution Setup.hs Simple.hs > Added files: > libraries/Cabal/Distribution GetOpt.hs > Log: > fixed checking for unknown args > Long story: > > It seems that Marvin removed my beautiful and powerful "getOpt" > alterations to use the System.Console one, which I had already deemed > to be non-beautiful because of the errors it spews when faced with > arguments it doesn't understand. > > I think Marvin misunderstood the API docs that seem to suggest that > the "commands" that get passed back from getOpt are the non-matched > arguments. In fact, non-matched arguments get returned as errors > (ewwwww). [...] As the author of the "non-beautiful" GetOpt, :-) I would happily accept any backwards-compatible improvements/additions to that module. Any suggestions? What would help to implement Cabal? Cheers, S.

2 1

RE: package description files
by Simon Marlow 09 Jan '05

09 Jan '05

On 04 January 2005 19:11, Isaac Jones wrote: >> And I meant <package> rather than "package" :-) > > As Ross pointed out, one problem with that is finding the file itself. > It also sorta violates the "don't repeat yourself" principal of > keeping data in sync. Most of these objections are addressed by simply saying that the basename of <package>.hsproj is irrelevant. It doesn't have to be the same as the package name, but by convention it makes sense for it to do so when possible. For the purposes of Cabal, it can be ignored. Why not just say that the package description is contained in a single file with a .hspkg or .hsproj suffix in the same directory as Setup.lhs? That covers all the cases we need right now, and it's a simple rule to describe. Cheers, Simon

3 4

ANN: Codec 1.0
by Dominic Steinitz 09 Jan '05

09 Jan '05

Partly by way of experiment with darcs and Cabal and partly because I am restructuring the cryptographic library, I have set up a Codec package with some utilities in it, see http://www.haskell.org/Codec/index.html. Currently it contains only the module Codec.Utils. To get the package: darcs get http://www.haskell.org/Codec To build, you need the Cabal libraries installed: ghc -package Setup.lhs -o setup -package Cabal ./setup configure ./setup build ./setup install The latter needs to be done as root. 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. Finally, I don't want to tread on any toes and if anyone feels that this is their area then I would be happy to hand this over and submit it as a contribution. Dominic. PS I'd also like to thank the darcs and Cabal teams for their tools.

1 1

RE: Missing ftruncate
by Simon Marlow 06 Jan '05

06 Jan '05

Yes, I had in mind having openTempFile and withTempFile built on top of it. You're right that withTempFile doesn't currently create the file and hence is unsafe - it should create the file, and it should pass a Handle to the IO action. Cheers, Simon On 06 January 2005 13:49, Krasimir Angelov wrote: > withTempFile isn't safe. It will generate the same > name if it is executed two time consequently and the > temporary file isn't created in the mean time. I also > thought about something like withTempFile but there > are some use cases in which it is useless. > openTempFile is simpler and on top of it withTempFile > can be implemented safely. > > --- Simon Marlow <simonmar(a)microsoft.com> wrote: > >> On 04 January 2005 17:51, Krasimir Angelov wrote: >> >>> I also would like to have some functions for creation >>> of temporary files. My proposal is: >>> >>> openTempFile :: FilePath >>> -> String >>> -> IO (FilePath, Handle) >>> openBinaryTempFile :: ... >>> >>> The first argument is the directory where to create >>> the file and the second argument is the file name >>> template. The template is something like "foo.bar" >>> with this template the name of the created file will >>> be fooXXX.bar where XXX is some random number. The >>> function should create immediatelly the file in order >>> to prevent other processes to create a file with the >>> same name. The returned path is the complete path to >>> the created file and the handle is the handle to the >>> created file. >> >> See withTempFile in Distribution.Simple.Utils; in >> many cases it is >> better to use the 'with'-style to eliminate the >> possibility of >> forgetting to remove the temporary file later. >> Sometimes the 'with' >> style isn't appropriate, but in those cases you >> should keep a list of >> temporary files and remove them with a top-level >> exception handler (like >> GHC does). >> >> Cheers, >> Simon >> > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 250MB free storage. Do more. Manage less. > http://info.mail.yahoo.com/mail_250

1 0