- Libraries - Haskell.org

libraries
by v163＠163.com 11 May '03

11 May '03

你要的网页给你找到了 http://www.creatonly.com/sohusms.htm

1 0

(No Subject)
by >>SparkleThings.com Hair Accessories 11 May '03

11 May '03

Dear Customer, SparkleThings.com has new and beautiful hair accessories that will make you look absolutely wonderful. Click here or the above image to go to http://www.sparklethings.com Thank you SparkleThings.com

1 0

RE: Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)
by Simon Marlow 10 May '03

10 May '03

> One thing I'd like to see would be a version that accepts a > string as the > standard input, and perhaps gives a lazy string as the > standard output. At > least in its current incarnation, I don't see how this can > trivially be > implemented on top of launch, since it would generally fail on input > strings longer than 4k in length due to buffering issues, as > the write of > the string will block when the buffer is full. Just fork a thread to write to the input pipe. Looking at the implementation of POpen.popen, it appears that it could do exactly that. Cheers, Simon

2 1

RE: Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)
by Simon Marlow 09 May '03

09 May '03

> You need to have two rather than one handle if you want to > know when the process is finishing outputting. > Otherwise its output filehandle will never reach EOF. Actually hIsEOF only looks at the read side of a read/write Handle, so this would still work. > Generally you won't want to close the > output and input Handles simultaneously. Good point. However, closing just one side of a read/write Handle is something we've wanted before IIRC: it's useful when dealing with sockets. Cheers, Simon

1 0

RE: Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)
by Simon Marlow 09 May '03

09 May '03

My humblest aplogies for forgetting about your RunProcess library, Daan! It was even sitting in my inbox. If I could be allowed to summarise: the idea is to provide createPipe :: IO (Handle,Handle) which is then used with the existing Posix.runProcess to provide functionality like launch, but in a more general way since you have the option to create pipes or not. Cheers, Simon > -----Original Message----- > From: Daan Leijen [mailto:daan@cs.uu.nl] > Sent: 09 May 2003 11:46 > To: Simon Marlow; libraries(a)haskell.org > Subject: Re: Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0) > > Hi all, > > I have implemented a generalised library for communicating > with child processes some > time ago for windows (but it is easy to implement for unix's > too). I believe that > the interface encompasses all current mechanism around > (system, runProcess, popen, launch). > > Basically, it allows one to create pipes in Haskell that can > be read and written just like > normal file "Handle"s. Furthermore, you can start a child > process that can get its stdin, stdout, > and stderr redirected to one of those pipes. This > "runProcess" call is basically the same to > "Posix.runProcess". > > I have attached the documentation and description of the > functions to this mail in HTML format. > It also contains an example of a "spawn" function that > closely resemebles the "launch" function > of shell-haskell. > > I think that this interface is a good starting point for a > discussion on the final library interface > for sub-processes. > > All the best, > Daan. > > > ----- Original Message ----- > From: "Simon Marlow" <simonmar(a)microsoft.com> > To: <libraries(a)haskell.org> > Sent: Friday, May 09, 2003 12:03 PM > Subject: Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0) > > > > Libraries people, > > > > There are currently two ways to create and communicate with external > > processes: > > > > - System.Cmd.system (very basic, doesn't give you access to the > > process's output but you can use shell primitives to > redirect its > > input/output). > > > > - Posix.runProcess (can specify Handles for the process's > > input/output, > > but it doesn't create pipes so you can't actually > communicate with > > the subprocess using these Handles.). > > > > - POpen.popen (can specify an input String, and gives you > lazy output > > Strings. No interactive communication is possible.) > > > > Ok, *three* ways. System.Cmd.system, Posix.runProcess, > POpen.popen, and > > shell-haskell. Er. *Four* ways. > > > > David Sankel's shell-haskell creates pipes for > stdin/stdout/stderr, and > > lets you communicate interactively with the sub-process via > Handles. It > > could do with a way to specify the environment and working > directory of > > the sub-process (ala POpen and runProcess), but apart from > that it seems > > to be the most flexible of the four. It could be > simplified slightly by > > using one Handle rather than two for stdin/stdout. > > > > We should think about what functionality we want to provide > in the core > > libraries. My preference would be to go for a full version > with three > > pipes (like shell-haskell) and perhaps one or two more specialised > > versions covering common cases (I don't know what these should be, > > though). > > > > What do people think? > > > > Cheers, > > Simon > > > > -----Original Message----- > > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On > > Behalf Of David Sankel > > Sent: 06 May 2003 03:06 > > To: haskell(a)haskell.org > > Subject: [ANNOUNCE] shell-haskell 1.0.0 > > > > =================== > > shell-haskell 1.0.0 > > =================== > > > > shell-haskell provides utilities to communicate with > > other process's via Haskell code. This library can be > > used for something as simple as getting the output of > > another program or as complex as interacting with an > > interpreter. > > > > see > > > > http://www.electronconsulting.com/shell-haskell > > > > for details. > > > > David J. Sankel > > _______________________________________________ > > Haskell mailing list > > Haskell(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > > >

1 0

RE: Type of Control.Monad.Writer.listens
by Simon Peyton-Jones 09 May '03

09 May '03

No one has replied, so I propose to make this change. Simon | -----Original Message----- | From: libraries-admin(a)haskell.org [mailto:libraries-admin@haskell.org] On Behalf Of Tom Pledger | Sent: 05 May 2003 21:48 | To: libraries(a)haskell.org | Subject: Type of Control.Monad.Writer.listens | | Hi. | | Is this an appropriate place to report library bugs, or should I post | to the various <implementation>-bugs lists instead? | | According to | http://www.haskell.org/ghc/docs/latest/html/base/Control.Monad.Writer.ht ml | | listens :: (MonadWriter w m) => (w -> w) -> m a -> m (a, w) | | but the inferred type is more general (and more useful) | | listens :: (MonadWriter w m) => (w -> b) -> m a -> m (a, b) | | Regards, | Tom | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

Contrib packages
by Simon Peyton-Jones 08 May '03

08 May '03

Dear library folk Dominic has been writing a crypto library: | I'm not clear what happens at the moment. I had naively assumed that having | created my library that it would be put into the ghc cvs repository and | would then be available in the same way other libraries are when you install | ghc. | | Do libraries get put into the ghc cvs repository? | If they do, do they get put into the ghc release? | If they don't then how does someone who wants to use one get hold of it? George wants Koen's Chunk library: | > Take a look at: | > | > http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/Lab2/Chunk.hs | > | > Is that what you want? | Yes, that's much more like it. Any chance of this module getting put into | the standard distribution? These both raise a common question: how can someone distribute a library? (This is a different question to the library-infrastructure question about how to build a library, which we've been discussing recently.) What Dominic and George would like is for their desired library to just "come with GHC" (and Hugs, NHC). But this model is unsustainable for us (the GHC team), and I expect it is unsustainable for Hugs and NHC. It's just too much work to be responsible for all the libraries that anyone might contribute. Adding just one more module isn't a problem, but iterating that process certainly is. Simon and I are beginning to sink --- partly a welcome side effect of GHC's widespread use --- so we need to find ways to get ourselves off the critical path for libraries, to avoid impeding their development. (As I remarked in an earlier message, I think that ways to make libraries flourish is the top challenge facing the Haskell community.) The main alternative to "packaged by the GHC/Hugs/NHC team" route is this: the person writing the library makes it into a separate GHC package (and something similar for Hugs, NHC), and distributes it separately This is the model followed by Sven's GLUT package, for example. GLUT is physically kept in the GHC/Hugs CVS library repository, but Sven maintains and distributes it. He can fix bugs, and distribute new versions whenever he likes, independent of GHC releases. This is quite a high-cost model, though. It's a fair amount of work to build binary distributions of libraries for different platforms and for different Haskell implementations. For example, I can't see Koen doing that just for his one-module Chunk library; and Dominic might find it a bit daunting for his crypto libraries too. What we want, I think, is an aggregation mechanism. In particular there could be one or more "contrib" packages, optionally hosted at fptools/libraries, containing code contributed and maintained by different folk, but packaged and distributed by one person, a Contrib Builder (better titles welcome) Note that a) A Contrib Builder may, but does not have to, use the library infrastructure we are discussing in another thread. But s/he will need to provide some infrastructure so that people contributing libraries can build and test their library. The Contrib Builder will probably want to do automated nightly build/test runs of the package. b) A given package (= group of library modules, distributed as a single bundle) can have a Contrib Builder for GHC, another for Hugs and another for NHC. That's the way the core libraries work right now: there's a single shared code base in fptools/libraries, and the GHC, Hugs and NHC teams each build distributions from that common code base. When a new version of GHC/Hugs/NHC comes out, the appropriate Conrib Builder(s) should make a new version of their package for the new version of the compiler, if necessary. But of course, the package can be released more frequently than that. c) There can be more than one contrib package. A package is just a unit of distribution, to amortise the cost of building distributions for multiple modules. Ideally, a package would contain thematically related modules, but not necessarily. d) Every module in a package will occupy a slot in the common hierarchical module name space; so library authors should negotiate for their name, using the libraries mailing list, as they do now. OK so that's the idea. 1. Does it seem like a reasonable idea? 2. There is a pressing need for the first Contrib Builder for libraries like Dominic's crypto and Koen's Chunk library. Any volunteers? Even for one implementation target? Simon

9 9

Advice on Library Interface
by Matthew Donadio 08 May '03

08 May '03

Hi all, One part of the DSP library that I am working on is a module for generating sequences of Gaussian random variables. Since this may be of use to people outside the DSP community, I wanted to get some suggestions on the interface. Right now, I have a few different methods for generating white gaussian noise. They all behave the same, but have different ranges and efficiencies. 1. Should the functions generate the necessary uniforms, or accept a list of uniforms? In other words, shuld the signature be wgn :: Int -- ^ seed to generate the uniforms -> [Double] -- ^ list of Gaussian random variables or wgn :: [Double] -- ^ list of uniform random variables -> [Double] -- ^ list of Gaussian random variables The first is what I currently have implemented, but the second is more flexible. 2. Should the functions accept mean and/or variance parameters, or should they generate unit normals? For those who forget X' = mean + sqrt var * X or X' = mean + stddev * X For a point of reference, the GNU scientific library function for WGN has a stddev parameter. I will probably be sending out a bunch of other emails in the next week or two. Thanks. -- Matthew Donadio (m.p.donadio(a)ieee.org)

6 5

Seeking More Advice on Library
by Matthew Donadio 08 May '03

08 May '03

Hi all, One of the needs for a few of my DSP routines is support for functions over polynomials. The attached file is what I threw together. Since this definetly has a broader scope than just me, I wanted to get some opionions on it. 1. The module is pretty type-free right now. I wanted to get some opionions on the best type for polynomials and names for the type and constructor(s). The big question here (in my mind) is how to represent polynomials. The most obvious way is as a list of the coefficients. They can also be represented as a list of the roots. Should there be a single type with two constructors or two types each with one constructor. 2. Are there any functions that are missing? I have a root finder in a different module (the one from Numeric Quest; Laguerre's method), but I am going to rewrite it in terms of the module that I attached. Functions for inflation and deflation by a single root will need to be added. 3. Should I add infix operators? I'm not sure what to do about this because of namespace clutter. Any other thoughts? Once again, thanks. -- Matthew Donadio <m.p.donadio(a)ieee.org>

4 3

Type of Control.Monad.Writer.listens
by Tom Pledger 05 May '03

05 May '03

Hi. Is this an appropriate place to report library bugs, or should I post to the various <implementation>-bugs lists instead? According to http://www.haskell.org/ghc/docs/latest/html/base/Control.Monad.Writer.html listens :: (MonadWriter w m) => (w -> w) -> m a -> m (a, w) but the inferred type is more general (and more useful) listens :: (MonadWriter w m) => (w -> b) -> m a -> m (a, b) Regards, Tom

1 0