January 2002 - Glasgow-haskell-users

Re: multithreading with multiprocessing (Was: Concurrent and Posix libraries...)
by Dean Herington 14 Jan '02

14 Jan '02

It turns out that, besides having a multithreaded process do `forkProcess` and `executeFile` "atomically", I also want to have a multithreaded process do `forkProcess` (without `executeFile`) and execute without any of the preexisting threads. This can be done by having a lock that all threads acquire before doing anything externally visible (roughly, any `IO` action), including, of course, the `forkProcess` itself. This solution, however, is cumbersome and probably inefficient. If a foreign function invocation designated "unsafe" is atomic with respect to the Haskell RTS, even when OS threads are used, there must be an internal mechanism in the Haskell RTS for temporarily running single-threaded. Why couldn't (and shouldn't) this mechanism be available to user programs? It would seem to be much cleaner and more efficient than the locking approach described above. Dean Simon Marlow wrote: > This example raises a general problem (which, as it turns > out, is relevant > to my current work). How can one mix multithreading with > multiprocessing? In particular, how can a threaded process > safely create > another process to run a program? Put another way, how can the > combination of `forkProcess` and `executeFile` be done > "atomically enough" > so that existing threads in the forking process don't "get in > the way". > > I read something on this topic (involving some sort of > pervasive locking > strategy) recently, but can't recall where. Anybody remember? I can't think of a good way to do this at the Haskell level, because you'd need to halt all the running threads except for the one doing the fork. But one hack which will work is to call out to a C function which does the fork/exec, since foreign calls will be atomic from the point of view of the Haskell RTS. However, one caveat which might be relevant in the future is that if the Haskell program is running in a multi-threaded environment (i.e. OS threads, not Haskell threads), then the C function must be marked 'unsafe' for it to be treated as atomic by the Haskell RTS. The OS thread support in the RTS isn't fully implemented yet, though. Cheers, Simon

1 0

Re: GHC Poll: scope in GHCi
by Ketil Z Malde 14 Jan '02

14 Jan '02

Koen Claessen <koen(a)cs.chalmers.se> writes: > | Does anyone have any better suggestions? > I think any solution that leaves it transparent as to if it > is a compiled or an interpreted module is fine. > But I have understood that this is hard to achieve... How about using a different command for importing the exported interface only? I.e. :l M --loads the whole (internal/top level) module :i M --"imports" the module's exported interface If :l requires interpretation, then so be it, otherwise use compiled modules whenever possible. I'm not sure I see the need for "namespace combinators" (ie. SM's suggested :m +M and so on) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: GHC Poll: scope in GHCi
by Simon Marlow 13 Jan '02

13 Jan '02

> | Does anyone have any better suggestions? > > I think any solution that leaves it transparent as to if it > is a compiled or an interpreted module is fine. I'm currently showing the scope in the prompt, with the modules from which we're taking the exports only surrounded by square brackets. Eg. [Prelude]> Just the exports of the Prelude are in scope [Prelude,IO]> The exports from Prelude and IO are in scope Main> The whole top-level scope of module Main Main[IO]> The whole top-level scope of Main, plus additionally the exports of IO A,B> The combined top-level scopes of A and B. So this doesn't really tell you which modules are compiled vs. interpreted but it does give you a good indication of what the current scope is. I can easily add another command to show the currently loaded modules, including which ones are interpreted - something like > :show modules Main ( Main.hs, interpreted ) Foo ( Foo.hs, Foo.o ) And maybe > :show bindings x :: Int f :: Int -> Bool Any other show-type things that might be useful? Cheers, Simon

3 2

Re: Yell
by Ashley Yakeley 12 Jan '02

12 Jan '02

At 2002-01-12 10:22, Hal Daume III wrote: >This seconds the yell. In the mean time Hugs has some documentation: http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/exts.html#sect7. 4 -- Ashley Yakeley, Seattle WA

1 0

Yell
by Ashley Yakeley 12 Jan '02

12 Jan '02

This message constitutes a yell. http://www.haskell.org/ghc/docs/latest/set/implicit-parameters.html Thanks in advance... -- Ashley Yakeley, Seattle WA

2 1

GHC version 5.02.2 is available
by Julian Seward (Intl Vendor) 12 Jan '02

12 Jan '02

The (Interactive) Glasgow Haskell Compiler -- version 5.02.2 ============================================================== We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.02.2. The source distribution is freely available via the World-Wide Web, under a BSD-style license. See below for download details. Pre-built packages for Linux, FreeBSD, Solaris, Alpha(OSF) and Win32 are also available, or will appear shortly. Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, C++, whatever). A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page at http://www.haskell.org/ GHC's Web page lives at http://www.haskell.org/ghc/ What's new in 5.02.2 ====================== Some important bugfixes: - fix for the long-standing "oversize heap-check" bug - networking library fixes: now works on Windows again - GHC's memory requirements should be improved over 5.02.1, especially when using --make. and many other minor fixes. How to get it =============== The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in InstallShield form for Windows folks. Everybody else gets a .tar.gz which can be installed where you want. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. On-line GHC-related resources =============================== Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ===================== To compile programs with GHC, you need a machine with 64+MB memory, GNU C and perl. This release is known to work on the following platforms: * i386-unknown-{linux,freebsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide included in distribution gives a complete run-down of what ports work; an on-line version can be found at http://www.haskell.org/ghc/docs/latest/building/building-guide.html Mailing lists =============== We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

4 4

Re: State Transformer
by Albert Lai 12 Jan '02

12 Jan '02

> > testfunc = do > > r <- newSTRef ('x',0) > > foo r > > bar r > > (c,n) <- readSTRef r > > return n Jorge Adriano <jadrian(a)mat.uc.pt> writes: > Yeap, I could do it like this myself :) > The whole problem is with passing the 'r' as a parameter, which is precisly > what I'm trying to avoid. I agree with you. My work-around is then to define foo and bar locally to testfunc, in the scope of r: testfunc = do r <- newSTRef ('x',0) let foo = do (c,n) <- readSTRef r writeSTRef r ('a', n+1) bar = do (c,n) <- readSTRef r writeSTRef r (c,n+2) foo bar (c,n) <- readSTRef r return n But if this looks like unsatisfactory (it does to me, too), perhaps you have to go back to DIY monads. DIY monads are good when: you fix the state variables, you don't want to mention them in subprogram parameters. The ST monad is good when: you create more state variables on the fly, you use mutable arrays, you don't want to write your own monad and put/get commands.

4 3

Re: State Transformer
by Ashley Yakeley 12 Jan '02

12 Jan '02

At 2002-01-11 06:18, Jorge Adriano wrote: >The whole problem is with passing the 'r' as a parameter, which is precisly >what I'm trying to avoid. You could always pass it implicitly (using -fglasgow-exts): -- testfunc = do r <- newSTRef ('x',0) (do foo bar with ?ref = r) (c,n) <- readSTRef r return n foo :: (Num a,?ref :: STRef s (Char,a)) => ST s () foo = do (c,n) <- readSTRef ?ref writeSTRef ?ref ('a', n+1) bar :: (Num a,?ref :: STRef s (t,a)) => ST s () bar = do (c,n) <- readSTRef ?ref writeSTRef ?ref (c,n+2) tryTestFunc = runST testfunc -- Curiously, GHC isn't smart enough to infer the types of foo and bar by itself. -- Ashley Yakeley, Seattle WA

1 0

Re: State Transformer
by Jan-Willem Maessen 11 Jan '02

11 Jan '02

Theodore Norvell <theo(a)cs.ubc.ca> asks: > Jorge's question raised a question in my mind. The IOExts > module has many of the same features as the ST module, why > are there two ways to do the same thing? Is the ST module > only there for legacy purposes? The ST monad provides safer encapsulation of mutable references. We can prove that references which escape a particular instance of ST are never side effected. See the paper "Lazy Functional State Threads": http://www.cse.ogi.edu/~jl/Papers/stateThreads.ps This allows us to construct functions which are certain to present a functional face to the world, but use mutation internally. In this respect, ST is actually "better" than IO, albeit less well-supported. -Jan-Willem Maessen [Note that the above paper presents the version of ST contained in the LazyST library these days (if my memory serves me right). The arguments about encapsulation apply in either case.]

2 1

Re: State Transformer
by Albert Lai 11 Jan '02

11 Jan '02

I will just translate your example from Norvell's DIY state monad to GHC's ST monad. As you noticed, GHC's ST monad begins with an "empty" state and you use some commands to add state variables as you go. This means the translation is not straightforward. I hope you still get the gist of it. Your hunch is correct: Norvell's applyST becomes GHC's runST. Your example uses two state variables: a Char and an Int, paired up as a tuple. Below, I use one state variable of type (Char,Int) for that, as hinted by your first attempt at the translation. foo and bar will each need to take a parameter --- the reference to the state variable, due to the reference business. testfunc = do r <- newSTRef ('x',0) foo r bar r (c,n) <- readSTRef r return n foo r = do (c,n) <- readSTRef r writeSTRef r ('a', n+1) bar r = do (c,n) <- readSTRef r writeSTRef r (c,n+2) tryTestFunc = runST testfunc

4 4