April 2005 - Libraries

Cryptography Library Licensing
by Dominic Steinitz 17 Apr '05

17 Apr '05

As you may be aware, I have collected together a set of coding / decoding and cryptographic functions written in Haskell and put them together in one package. I have just modified the package and am on the point of announcing the new much improved version using cabal and darcs. A pre-release of the package is available at http://www.haskell.org/Codec/. One of the final things I need to do is ensure that the licenses are correct. It would be very helpful to me as the package maintainer if you, the authors, could agree on one license otherwise I will have to write a special license file (something I am keen to avoid as I am not a lawyer). My suggestion is that that we all use the Modified BSD license from http://www.fsf.org/licensing/licenses/license-list.html#ModifiedBSD which I reproduce below. This would be prepended by a copyright notice for the authors. Please can you either a) email with your acceptance of this or b) send me a license for your portion of the package which would be acceptable to you. I would much prefer the former as it would significantly reduce the amount of work for me. Many thanks, Dominic. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

1 0

StateT example (an encore performance)
by Isaac Jones 16 Apr '05

16 Apr '05

I noticed a few bits lacking in the Control.Monad.State documentation. I think an example of using StateT to encapsulate IO would be a useful addition... In order to make StateT more interesting, the trick is to use a lift inside a function that returns StateT, so you can actually perform IO. I would guess that this is the kind of use case that most people would want to use StateT, but lift isn't mentioned in the docs. Also, the types of "runStateT" and "runState" are a little confusing, since they're actually field accessor functions, so I'd like to make a note on that. So how 'bout I add an example like the following to the State documentation? module Main where import Control.Monad.State type MyState a = StateT Int IO a stateFun :: MyState String stateFun = do modify (+100) liftIO (putStrLn "Hello!") return "foo" main = do (s, n) <- runStateT (stateFun >> stateFun) 0 putStrLn $ "n: " ++ (show n) ++ " s: " ++ s peace, isaac

2 2

Cabal Installing Executables
by Dominic Steinitz 16 Apr '05

16 Apr '05

When I run ./Setup install, the executables end up in /usr/local/bin which is not where I want them and not with the right permissions. Can someone tell me what I have to do to install the executables in the current directory or my home directory and also set the permissions (and ownership) to be that of the installer? Thanks, Dominic. Here's part of the cabal file: Executable: BERTest Main-Is: BERTest.hs Other-modules: Codec.ASN1, Codec.ASN1.BER and here's what happens to the executables in /usr/local/bin: -rwxr--r-- 1 root root 1317323 Apr 16 07:40 X509Example* -rwxr--r-- 1 root root 1555872 Apr 16 07:40 SymmetricTest* -rwxr--r-- 1 root root 1584127 Apr 16 07:40 RSAEncryptionExample* -rwxr--r-- 1 root root 1351135 Apr 16 07:40 PKCS8Example* -rwxr--r-- 1 root root 915278 Apr 16 07:40 BERTest*

1 0

Do you use GHC?
by Simon Peyton-Jones 16 Apr '05

16 Apr '05

Dear Haskell folk, PLEASE READ THIS IF YOU USE THE Glasgow Haskell Compiler (GHC). I virtually never send messages to overlapping sets of lists, but I'm doing so this time, because I'd really like to get to everyone who uses GHC. Here at GHC HQ, we are often asked how many people use GHC, and what kind of folk they are. Since GHC is free software, we have no clue. Download stats tell us a bit, but not much, because GHC gets out through a variety of other routes too (e.g. Debian). We also have little idea about which aspects of GHC are most valued, nor of what enhancements would be most sought after, or which platforms are most important to you. We hear quite a bit from the bleeding-edge folk who push the limits, but much less from people who just want to get the job done. Thus motivated, Tomasz Zielonka kindly put together a (WASH-powered) survey for us, which asks you to tell us a bit yourself and how you use GHC. We've had about 230 responses so far; thank you to those 230 folk. But I'm pretty certain there are more than 230 people in the world who use GHC! THIS MESSAGE IS TO ASK YOU TO TAKE 5 MINS TO COMPLETE THE SURVEY http://www.haskell.org/ghc/survey/start.cgi We'd like to hear from *absolutely everyone* who uses GHC: whether you are a first-year undergraduate or a famous professor; whether you use GHC for industrial applications or recreation; whether you use higher-rank polymorphism or have only just learned what functional programming is. Everyone! We'll use the information to guide our future priorities, and we'll publish some kind of summary of what we learn in due course. It's all anonymous, of course, unless you choose to say who you are. If you think it's appropriate, please circulate this announcement locally, e.g. to your students who may not be on the Haskell mailing list Many thanks Simon PJ and Simon Marlow

1 0

replacement for popen
by Uwe Schmidt 15 Apr '05

15 Apr '05

in the ghc-6.4 release the posix module is deprecated. I'm looking for a replacement and tried the System.Process functions. the following first try does not work for large files. it blocks if the file "long.file" does not fit into one os-buffer. then cat blocks and therefor waitForProcess blocks ------------------------------------ module Main where import IO import System import System.Process main :: IO () main = do (inpH, outH, errH, pH) <- runInteractiveProcess "cat" ["long.file"] Nothing Nothing hClose inpH res <- hGetContents outH errs <- hGetContents errH rc <- waitForProcess pH putStrLn ("rc: " ++ show rc) putStrLn ("stdout: " ++ res) putStrLn ("stderr: " ++ errs) exitWith rc ---------------------- the following version works fine, but it looks very much like a hack --------------------- module Main where import IO import System import System.Process main :: IO () main = do (inpH, outH, errH, pH) <- runInteractiveProcess "cat" ["long.filel"] Nothing Nothing hClose inpH res <- hGetContents outH errs <- hGetContents errH if (length $! res) == 0 -- hack !!! then return () else return () if (length $! errs) /= 0 -- hack !!! then return () else return () rc <- waitForProcess pH putStrLn ("rc: " ++ show rc) putStrLn ("stdout: " ++ res) putStrLn ("stderr: " ++ errs) exitWith rc ------------------------------------- is there a simple replacement for the popen using the System.Process module? uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html mail:uwe@fh-wedel.de tel:++49-4103-8048-45

3 2

RE: import resolution (was RE: exposed packages and cabal depends)
by Simon Marlow 14 Apr '05

14 Apr '05

Think of it like this: a collection of Haskell source files often share common dependencies. Those dependencies include packages, but also things like what C libraries and header files are required by the code, and what extra GHC flags might be required to compile it. We find it convenient to put all this information in one place: the .cabal file. You can think of .cabal as part of the source if that helps. It really is part of the source - but implemented and specified as a layer on top of existing language and compiler technology, for convenience and so that we can share the tools. When all the dependencies are explicit, the code is portable. That's what you're arguing for - but we're already there. All you have to do is write a .cabal file, cut-and-paste a 3-line Setup.lhs file, and you're done. And for free, we'll throw in a multi-compiler, multi-platform build system and automated installation. But that's not all! Get Cabal, and later we'll also give you automated dependency download and installation, automated binary package generation in a variety of formats, automated publishing and lots more. Cheers, Simon

1 0

RE: import resolution (was RE: exposed packages and cabal depends)
by Simon Marlow 14 Apr '05

14 Apr '05

On 12 April 2005 19:58, S. Alexander Jacobson wrote: > My main goal here is to free the user from the hassle of manual > package installation. A module written in one location should "just > work" when moved to another. Rather than expoect modules to "just work" when moved from one location to another, I think it's more reasonable to expect *packages* to just work. This is the basis on which the package system and Cabal is built. Build and run dependencies are more than just the modules that the source code imports. Take a look at what's in a Cabal description: you'd need to put most of that in the source code to make portable modules. It's not practical, and I argue that the source code is the wrong place for that stuff. > And, if the meaning of module names is parametrized by package then > package names should be part of import statements. If packages are > purely adminisistrative, then they shouldn't. Yes, modules are parameterised by package, but no, I don't agree that packages should be specified in the source code. You really don't want to have to write import base>=1.0 Data.List all over the place. Or maybe you do? > PS In my last few posts I assumed you had rejected removing the > overlap restriction because that is what I interperted you to have > said e.g. here: > > We're not going to support this, at least for the forseeable > future. It's a pretty big change: every entity in the program > becomes parameterised by the package name as well as the module > name, because module names can overlap. > > http://www.haskell.org//pipermail/haskell/2005-March/015597.html Ok, I was perhaps a little sronger than I intended in that message. The overlap restriction is there for engineering reasons, it's not a fundamental problem, and one day it might be lifted. FWIW, I think we all agree that it sucks. > And here > > Also, the Haskell module hierarchy is supposed to reflect > functionality, whereas package names are purely administrative. > This is a reason for not including package names in source code. > > http://www.haskell.org//pipermail/libraries/2005-April/003513.html > > Did you change your mind or am I misinterpreting? My position on that hasn't changed. Cheers, Simon

3 2

RE: replacement for popen
by Simon Marlow 13 Apr '05

13 Apr '05

On 12 April 2005 16:38, David Brown wrote: > On Tue, 12 Apr 2005 14:22:00 +0200, Uwe Schmidt <uwe(a)fh-wedel.de> > wrote: > >> in the ghc-6.4 release the posix module is deprecated. > > I assume you're referring to popen not being available. I hope that > all of System.Posix isn't being deprecated. No, only the old Posix library in hslibs is deprecated. System.Posix is the replacement. Cheers, Simon

1 0

RE: replacement for popen
by Simon Marlow 13 Apr '05

13 Apr '05

On 13 April 2005 07:53, Uwe Schmidt wrote: > I tried > >> forkIO(evaluate(length res) >> return ()) > > but this version again blocks. You are compiling with -threaded, right? It's needed for non-blocking waitForProcess. The docs do mention this. Cheers, Simon

1 0

RE: replacement for popen
by Simon Marlow 13 Apr '05

13 Apr '05

On 12 April 2005 13:22, Uwe Schmidt wrote: > in the ghc-6.4 release the posix module is deprecated. > I'm looking for a replacement and tried the > System.Process functions. the following first try > does not work for large files. it blocks if the > file "long.file" does not fit into one os-buffer. > then cat blocks and therefor waitForProcess blocks > > ------------------------------------ > > module Main where > > import IO > import System > import System.Process > > main :: IO () > main = do > (inpH, outH, errH, pH) <- runInteractiveProcess "cat" > ["long.file"] Nothing Nothing hClose inpH > res <- hGetContents outH > errs <- hGetContents errH > > rc <- waitForProcess pH > > putStrLn ("rc: " ++ show rc) > putStrLn ("stdout: " ++ res) > putStrLn ("stderr: " ++ errs) > exitWith rc > > ---------------------- > > the following version works fine, but it looks very much like a hack > > --------------------- > > module Main where > > import IO > import System > import System.Process > > main :: IO () > main = do > (inpH, outH, errH, pH) <- runInteractiveProcess "cat" > ["long.filel"] Nothing Nothing hClose inpH > res <- hGetContents outH > errs <- hGetContents errH > > if (length $! res) == 0 -- hack !!! > then return () > else return () > > if (length $! errs) /= 0 -- hack !!! > then return () > else return () > > rc <- waitForProcess pH > > putStrLn ("rc: " ++ show rc) > putStrLn ("stdout: " ++ res) > putStrLn ("stderr: " ++ errs) > exitWith rc If you really must use hGetContents, then the hack above is necessary: you have to force the output strings before waiting for the process to terminate. This would be slightly cleaner: > res <- hGetContents outH > errs <- hGetContents errH > forkIO (evaluate (length res)) > forkIO (evaluate (length errs)) which avoids blocking the main thread, but ensures that all the data gets pulled as it becomes available. It looks like the same hack would be required with the old POpen interface too - if not, can you show an example of something that works with popen but not with System.Process? Cheers, Simon

2 1