- Libraries - Haskell.org

replacement for popen
by Uwe Schmidt 14 Apr '05

14 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 13 Apr '05

13 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 13 Apr '05

13 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

RE: Module Holism (was RE: exposed packages and cabal depends)
by Simon Marlow 12 Apr '05

12 Apr '05

On 12 April 2005 01:28, S. Alexander Jacobson wrote: > On Mon, 11 Apr 2005, Simon Marlow wrote: >>> The problem is, we don't want to import two modules, only to >>> discover that somewhere in their dependencies they each use the >>> same module name to refer to conflicting module implementations. >> >> This is the problem that the overlap restriction leads to, yes. > > No, you have this problem even with atomic modules. It is a result > simply of not allowing two modules to share the same name in the same > program and has nothing to do with package overlap. When I say "overlap restriction" I mean the restriction that prevents having two modules with the same name in the same program. >>> Therefore, we really want to say that no two modules we might want >>> to import into our programs (either directly or indirectly) should >>> share the same name. And, in particular, we don't want a packaging >>> or versioning system that encourages it! >> >> No, you've drawn a bogus conclusion again. We most definitely want >> the ability to choose between multiple instances of a particular >> module in programs. > > My point is that the choice of instance should be made at > compile/build/run times and not at packaging time. Dependencies must be expressed at package time, otherwise they are untracked dependencies. Right? A package must state that it needs implementation P of module M rather than implementation Q, otherwise there's a chance that the guy building the package will get the wrong one. Build-depends lets you select an implementation from a range (currently it's just a version range, but we could make the language more expressive and include alternatives, I doubt it would be that useful in practice, though). So dependencies are selected at compile time. Selecting dependencies at run-time (I assume this is what you mean by late binding) is another kettle of fish: at least, it would mean that GHC couldn't do its aggressive cross-module optimisation against the library that you're late-binding to. But I think it's worthwhile investigating to what extent this is possible, so that we can have upgradable shared libraries. >> For example, if I have two versions of a package installed, >> say P-1 and P-2, I want to be able to compile my old code that >> depends on P-1 while still being able to write new code against P-2. >> And I want to be able to use other packages that still depend, for >> the time being, on P-1. When P-3 comes out, I don't want to be >> forced to uninstall P-1 and P-2 before I can use it. > > Now what happens when you want to use one package that depends on P-1 > and another that depends on P-2 at the same time? Of course, you can't do that. That's what the "overlap restriction" prevents. As I've explained. [ the next three paragraphs, which I deleted, all complain about scenarios which we can't handle because of the overlap restriction. I don't think I need to comment any further. ] [ more stuff deleted, this thread is too long already ] Cheers, Simon

3 2

[ANN] SDL 0.2
by Lemmih 12 Apr '05

12 Apr '05

Greetings, In the spirit of release early, release often, I hereby announce SDL[1] 0.2, a Haskell binding to libSDL[2] and various addons[3]. It is a cabal[4] package and has been tested with GHC 6.4 and Hugs 20050308. -- Friendly, Lemmih [1] http://www.scannedinavian.org/~lemmih/SDLstable/dist/SDL-0.2.tar.gz [2] http://www.libsdl.org/ [3] http://www.ferzkopp.net/~aschiffler/Software/SDL_gfx-2.0/, http://www.libsdl.org/projects/SDL_image/, http://www.libsdl.org/projects/SDL_mixer/ and http://www.libsdl.org/projects/SDL_ttf/. [4] http://www.haskell.org/cabal/

1 0

RE: Module Holism (was RE: exposed packages and cabal depends)
by Simon Marlow 11 Apr '05

11 Apr '05

On 11 April 2005 18:58, S. Alexander Jacobson wrote: > You said that no two modules in a program can share the same name. > > At the same time, we want a library system that allows us to use any > combination of modules in any program. > > The problem is, we don't want to import two modules, only to > discover that somewhere in their dependencies they each use the > same module name to refer to conflicting module implementations. This is the problem that the overlap restriction leads to, yes. It is mitigated by the fact that the granularity of dependencies is made coarser by the packaging system, so we believe it will rarely be a problem in practice. Remember, when you're importing library modules, your dependencies are on *packages*, not modules. > Therefore, we really want to say that no two modules we might want to > import into our programs (either directly or indirectly) should share > the same name. And, in particular, we don't want a packaging or > versioning system that encourages it! No, you've drawn a bogus conclusion again. We most definitely want the ability to choose between multiple instances of a particular module in programs. For example, if I have two versions of a package installed, say P-1 and P-2, I want to be able to compile my old code that depends on P-1 while still being able to write new code against P-2. And I want to be able to use other packages that still depend, for the time being, on P-1. When P-3 comes out, I don't want to be forced to uninstall P-1 and P-2 before I can use it. This restriction on module overlaps is mainly for engineering reasons, as I've explained before. Someday it might be lifted, and we want the design of the system to extend gracefully when that happens, which the current design will. > Build-depends assumes it is useful to talk about dependencies with > respect to a given package, when in fact, all modules have to share > the same namespace. -hide-all-packages assumes it is useful to talk > about dependencies with respect to a given system when, in practice, > all users should be in as similar a namespace as possible. In effect > -hide-all-packages encourages untracked dependencies on some very > local namespace. Sorry, I don't understand that paragraph at all. > What we want is a common system for mapping module names to > module implementations. > > * a protocol for resolving module-names to implementations at > various haskell module name servers (hackage?) Go ahead, invent a protocol! > * support for addition and overrides by specific communities > (proxies?) > > * support for creation of new versions by individuals (-i override?) > > And we need to constraint the versioning system to require that > every new version of a module must fulfill the contracts of the > prior versions so no existing dependency is broken by any changes. That's way too restrictive. We'd never be able to remove anything. Furthermore, for GHC, you can't actually upgrade a library in place. Libraries that were built against the previous version will break, because in GHC the "contract" between compiled modules is extremely intimate (in includes a lot more than the exported interface of the modules). When we start using shared libraries, even binaries will break if you upgrade shared libraries in place. That's why we must have versioning, and the ability to have multiple versions of a package installed. Cheers, Simon

2 2

RE: exposed packages and cabal depends
by Simon Marlow 11 Apr '05

11 Apr '05

On 08 April 2005 22:24, S. Alexander Jacobson wrote: > The -hide-all-packages option would make sense only if there were real > flexibility in selecting which packages to use in implementing the > modules imported into your program. However, in our discussions, you > you've defined two rules that eliminate this flexibility: > > * you cannot use two different modules with the same module ID in the > same program > > * you cannot use two different packages with the same module ID in the > same program > > Together these constraints imply that packages should contain only > minimal sets of mutually interdependent modules; every additional > module included in a package restricts its usability. So, if no two > packages should contain the same module name, one must therefore > conclude: > > Package Dependency Rule: The module names used in a program > completely specify the packages required to interpret/compile it. No, that doesn't follow. You can most certainly have lots of packages with the same module, you just can't use them in the same program. How do you think we plan to have multiple versions of packages? [ stuff about the -i overriding problem deleted... I'll think about it and post to a new thread.] > To be clear, my problem with -hide-all-packages is that it creates > much greater risk of getting out of sync with the global table. > Build-depends tags are actively bad because you cannot know the nth > degree dependencies of the packages you are using. Correctness is > only with respect to the global table. Yes, the user has to know about dependencies because of the overlap restriction. But dependencies are completely visible: you *can* know the dependencies of the packages you're using. I'm not sure what you mean by "global table". One day we'll lift the overlap restriction and things will get easier, but not right now (unless you have a patch!). > Yes, I am begging the question of how we construct and manage global > tables in a way that preserves free-packaging/decentralization. > (Perhaps it is with user specifiable hackage tables) But, there is > no point in talking about solutions until we agree on the problems > that need to be solved. At this point I'm a bit hazy on what problem you still think needs to be solved :-) We've eliminated untracked dependencies from Cabal packages. At some point, we'll generalise package names to URLs (assuming community agreement and a concrete proposal). Hackage will be providing a centralised package repository for those that want it. Cheers, Simon

2 1