May 2003 - Libraries - Haskell.org

RE: Foreign.GreenCard.StdDIS (was Re: X11 libraries)
by Simon Marlow 15 May '03

15 May '03

> When I got back to work on putting an HGL release together, I > realized that > I'd have to do a fresh release of GreenCard first since it > has a bunch of > updates to work with hierarchial names, ffi, etc. The > GreenCard distrib > contains what ought to be the master copy of the > StdDIS.{gc,hs} so I figure > it ought to be made a proper library package, put in the > hierarchial library > namespace, etc. Obvious places to put it in the library > hierarchy are: > > Foreign.GreenCard.StdDIS.hs > GreenCard.StdDIS.hs > Apps.GreenCard.StdDIS.hs > <SomeOtherPrefix>.GreenCard.StdDIS.hs There is reasonable justification for each of these - I don't have any strong preferences. Malcolm prefers Foreign.GreenCard.hs; that's fine by me. > (btw it seems like we might see more apps with support > libraries -especially > if the app generates Haskell code- so this may be an instance > of a more general problem.) FWIW, in Happy and Alex I just copy some boilerplate code directly into the generated Haskell to avoid this problem. The boilerplate isn't baked into the Happy or Alex binary, it's installed as a separate file. > [btw GreenCard raises an additional issue for any library > building/ packaging > infrastructure. If you want to use GreenCard, you need > StdDIS.gc and (the > makefile which invokes) GreenCard needs to know where to find > it. So we need > a standard place for it to live or a way to locate it once installed.] We've solved this problem several times (GHC, hsc2hs, Happy, Alex, Haddock). The solution I normally use for Unix systems is to have a small script which invokes the main binary passing it a flag which indicates the location of its auxiliary files (usually something like /usr/local/lib/happy). You can build a location-independent binary package which just fiddles with this script at install time. On Windows, it's rather easier because a binary can get at its own filesystem location at runtime. This all assumes the user normally wants the standard StdDIS.gc and won't want to fiddle with it, I guess. Cheers, Simon

1 0

RE: Hierarchical libraries document updated
by Simon Marlow 15 May '03

15 May '03

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > I've updated the document at > > http://www.haskell.org/~simonmar/libraries/libraries.html > > to reflect some changes in how the libraries situation is evolving. > > The latest version of the libraries document is looking good, and > thanks for keeping it rolling Simon. No problem! > In the section on Portability, bit-wise operations (i.e. Data.Bits) > are noted as non-portable, yet as far as I'm aware they are supported > by all the implementations now. Would anyone object if I move that > bullet item to the section on "extensions that can be assumed > portable"? Yes, please do. I was vaguely aware that NHC had adopted Data.Bits, but hadn't got around to checking that fact. > Also, in section 4.4, the allocation of libraries to maintainers is > a somewhat rough approximation, I'd say. No doubt we can gradually > refine it. For instance, Debug.QuickCheck.* is currently allocated to > this mailing list, but I'm sure it should really be under the control > of John Hughes and Koen Claessen - I know that they are planning a new > release soon. Sure. > I have never heard of the System.DL library before, and couldn't > guess from the name what functionality it aimed to provide. I had > to go look at the source code to determine what it does! A definite > candidate for clearer naming - I would suggest System.DynamicLinker > or something along those lines. Yes. System.DL is a Haskell interface to the Unix libdl library, which in fact appears to be part of the latest revision of the POSIX standard, so it should probably be called System.Posix.DyamicLinker. I just noticed on my ToDo list for System.Posix I have it down as System.Posix.DynamicLoader. Volker, what do you think about renaming it to one of these? Cheers, Simon

2 1

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

12 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

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