Re: [grapefruit] can't run Grapefruit
I decided to try on Max OS X (10.5). It seemed to get a bit further, but still no joy. Anyone have a suggestion? bash-3.2$ ghci GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Graphics.UI.Grapefruit.Circuit Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + Examples.Grapefruit.Simple Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK Examples.Grapefruit.Simple> run GTK mainCircuit Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.2 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package QuickCheck-2.1.0.1 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package filepath-1.1.0.2 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. Loading package directory-1.0.0.3 ... linking ... done. Loading package process-1.0.1.1 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package glib-0.10.0 ... linking ... done. Loading package cairo-0.10.0 ... linking ... done. Loading package gtk-0.10.0 ... linking ... done. Loading package TypeCompose-0.6.4 ... linking ... done. Loading package lazysmallcheck-0.3 ... linking ... done. Loading package Stream-0.3.1 ... linking ... done. Loading package arrows-0.4.1.1 ... linking ... done. Loading package grapefruit-frp-0.0.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package type-level-0.2.2 ... linking ... done. Loading package type-equality-check-0.0.0.0 ... linking ... done. Loading package grapefruit-records-0.0.0.0 ... linking ... done. Loading package grapefruit-ui-0.0.0.0 ... linking ... done. Loading package grapefruit-examples-0.0.0.0 ... linking ... done. Loading package grapefruit-ui-gtk-0.0.0.0 ... linking ... done. *** Exception: Cannot initialize GUI. At 3:58 PM -0400 5/23/09, Dean Herington wrote: I'm trying to give Grapefruit a try. I installed it as described in section 4.1 of http://www.haskell.org/haskellwiki/Grapefruit. When I tried to run the Simple.hs example, I got the problem shown below. Any ideas? My machine is running Windows XP Pro 2002 SP3. TIA Dean GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Graphics.UI.Grapefruit.Circuit Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + Examples.Grapefruit.Simple Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK Examples.Grapefruit.Simple> run GTK mainCircuit Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.1 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package Win32-2.2.0.0 ... linking ... done. Loading package filepath-1.1.0.1 ... linking ... done. Loading package directory-1.0.0.2 ... linking ... done. Loading package process-1.0.1.0 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL: could not load DLL) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
can't run Grapefruit
I'm trying to give Grapefruit a try. I installed it as described in section 4.1 of http://www.haskell.org/haskellwiki/Grapefruit. When I tried to run the Simple.hs example, I got the problem shown below. Any ideas? My machine is running Windows XP Pro 2002 SP3. TIA Dean GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Graphics.UI.Grapefruit.Circuit Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + Examples.Grapefruit.Simple Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK Examples.Grapefruit.Simple> run GTK mainCircuit Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.1 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package Win32-2.2.0.0 ... linking ... done. Loading package filepath-1.1.0.1 ... linking ... done. Loading package directory-1.0.0.2 ... linking ... done. Loading package process-1.0.1.0 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL: could not load DLL) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HUnit 1.2.0.0 on 6.8.1 vs 1.1.1 on 6.6.1
Sorry, I've not been able to follow the Haskell lists very regularly recently. I'll try look into the problem soon. Dean At 10:46 AM -0800 12/10/07, Greg Fitzgerald wrote: > >> > "abc" @=? "efg" >> Loading package HUnit-1.2.0.0 ... linking ... done. >> *** Exception: (unknown) On Dec 3, 2007 7:23 AM, Ian Lynagh <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: > This is caused by a change in the HUnit library, from >assertFailure msg = ioError (userError (hunitPrefix ++ msg)) > to >assertFailure msg = E.throwDyn (HUnitFailure msg) I've had no luck contacting Dean Herington using the email address posted on the HUnit page. They just use the latest version in the darcs repositories at the time that they are built Sounds like this is the first case where the latest version isn't a stable one (Go Haskell!). Is it much trouble for package maintainers to package GHC with HUnit.1.1.1? To keep it simple, maybe there should be an HUnitStable branch where 1.1.1 is the latest version? Thanks, Greg___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: simple question
At 10:56 PM +0200 4/2/05, Benjamin Franksen wrote: On Saturday 02 April 2005 22:29, Peter Hercek wrote: What is $ function good for? Mostly for avoiding parentheses. $ is right associative and has lowest precedence, whereas normal application is left associative and binds most tightly: f $ g $ h x === f ( g ( h x ) ) There are more advanced uses of $ but I'll let others elaborate on that. Ben The other main use is to have a name for function application. For example, zipWith ($) [sin, cos, tan] [0, 1, 2] Dean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
#! for GHC?
Can GHC be invoked somehow via the #! mechanism? Put another way, is there a GHC analogue to runhugs? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: child process statistics
On Wed, 26 Feb 2003, Sigbjorn Finne wrote:
> wait3() or getrusage()? (Neither of which are supported
> by the posix library.)
>
> --sigbjorn
Thanks, Sigbjorn. I drafted a Haskell wrapping of wait4(), modeled on
code I found in CVS. See attached. I'd like a bit of help in two
respects:
1. I found it difficult to satisfy the code requirements because I'm
building the module outside the RTS build environment. Some issues:
a. I don't know how to make a .hsc file, which would be the appropriate
form for the file, I think. This meant I couldn't use #const, and may
also explain why I couldn't find the __hsunix_* routines.
b. I had to duplicate some helper functions, including `waitOptions` and
`decipherWaitStatus`, because they didn't seem to be exported from the
module in which they're defined.
c. I'm not sure how to define `struct timeval` and `struct rusage` so I
can avoid the kludgy code in `makeProcessResourceUsage`.
It seems that maybe I should be building in the RTS environment (and
maybe even extending the System.Posix.Process module itself) to clean
up all of the above problems. That seems a bit daunting to me, however.
2. Having gotten my module to compile cleanly, it--not surprisingly--fails
at runtime:
invalid argument
Action: reapChildProcess
Reason: Invalid argument
Maybe a few minutes of your eyes (or those of anyone else who has delved
in the RTS) would spot the problem(s) quickly. I tried gdb and saw what
appear to me to be reasonable arguments to wait4(), but I'm over my head
here.
Thanks in advance.
Dean
> - Original Message -
> From: "Dean Herington" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, February 26, 2003 16:17
> Subject: child process statistics
>
>
> > Does anyone know how to get the process statistics (cputime, page faults,
> > etc.) for a child process? When the child process has terminated, before
> > doing getAnyProcessStatus on it, I'd like to get its statistics.
> >
> > Browsing the libraries documentation didn't turn anything up. I couldn't
> > even find what I want at the Unix level among man pages. (I'm happy to
> > write some FFI code to access system routines if I can locate the right
> > ones.)
> >
> > Dean
{-# OPTIONS -fglasgow-exts #-}
-- Posix extras
-- $Id$
module PosixExtras
(
ProcessResourceUsage(..),
reapChildProcess
)
where
import Ratio
import System
import Posix hiding (userTime, systemTime)
import System.IO.Error
import Foreign
import Foreign.C
data ProcessResourceUsage =
ProcessResourceUsage { userTime, systemTime :: Rational }
deriving (Show, Read)
reapChildProcess :: Bool -> Bool -> ProcessID
-> IO (Maybe (ProcessID, ProcessStatus, ProcessResourceUsage))
reapChildProcess block stopped pid =
alloca $ \p_wstat ->
allocaBytes structRusageSize $ \p_sru -> do
pid' <- throwErrnoIfMinus1 "reapChildProcess"
(c_wait4 (fromIntegral pid) p_wstat
(waitOptions block stopped) p_sru)
case pid' of
0 -> return Nothing
_ -> do ps <- decipherWaitStatus p_wstat
pru <- makeProcessResourceUsage p_sru
return (Just (fromIntegral pid', ps, pru))
type CPid = CInt
structRusageSize = 144 -- I think it's 72. Include 100% slop.
type CRusage = CLong -- cheat
makeProcessResourceUsage :: Ptr CLong -> IO ProcessResourceUsage
makeProcessResourceUsage p_sru = do
-- Assume that ru_utime and ru_stime are at the beginning of struct rusage.
[uhi, ulo, shi, slo] <- mapM get [0..3]
let u = time uhi ulo
s = time shi slo
return $ ProcessResourceUsage{ userTime = u, systemTime = s }
where
get n = fmap fromIntegral $ peekElemOff p_sru n
time hi lo = toRational hi + (lo % 100)
foreign import ccall unsafe "wait4"
c_wait4 :: CPid -> Ptr CInt -> CInt -> Ptr CRusage -> IO CPid
-- The following was scarfed from
-- fptools/libraries/unix/System/Posix/Process.hsc?rev=1.4
waitOptions :: Bool -> Bool -> CInt
-- block stopped
waitOptions False False = 1 -- (#const WNOHANG)
waitOptions False True = 3 -- (#const (WNOHANG|WUNTRACED))
waitOptions True False = 0
waitOptions True True = 2 -- (#const WUNTRACED)
-- Turn a (ptr to a) wait status into a ProcessStatus
decipherWaitStatus :: Ptr CInt -> IO ProcessStatus
decipherWaitStatus wstatp = do
wstat <- peek wstatp
if c_WIFEXITED wstat /= 0
then do
let exitstatus = c_WEXITSTATUS wstat
if exitstatus == 0
then return (Exited ExitSuccess)
else return (Exited (ExitFailure (fromIntegral exitstatus)))
else do
if c_WIFSIGNALED wstat /= 0
then do
let termsig = c
child process statistics
Does anyone know how to get the process statistics (cputime, page faults, etc.) for a child process? When the child process has terminated, before doing getAnyProcessStatus on it, I'd like to get its statistics. Browsing the libraries documentation didn't turn anything up. I couldn't even find what I want at the Unix level among man pages. (I'm happy to write some FFI code to access system routines if I can locate the right ones.) Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MArray and runST
Simon Peyton-Jones wrote: > Interesting example! > > | Coincidentally, I tripped over this subtlety myself just last night. > (I, > | too, often use '$' to avoid nested parentheses.) I concluded it was > an > | instance of the "partial-application restriction" that I found > described in > | section 7.11.4 of the GHC 5.02 User's Guide (still accessible at the > GHC web > | site if you look carefully enough). > > No, that's not the reason. That restriction has been lifted. > > Consider this simpler program; > > foo = id runST > > Now we have > id :: forall a. a -> a > > So to apply 'id' to 'runST' we'd have to instantiate the type variable > 'a' to runST's type > 'forall b. (forall s. ST s b) -> b' > > But GHC only implements predicative polymorphism; it does not allow you > to instantiate a type variable with a for-all type. It would be nice to > lift this restriction, but I don't know how do to so without losing type > inference. > > Now, the error message you get is deeply obscure, I grant you. Trouble > is, this variant IS ok: > > foo = id wibble > > wibble :: ((forall s. ST s b) -> b) -> b > > Why? For the same reason that this is OK > > foo = id reverse > > That, is we can instantiate the type of the argument to a monotype (a > type without for-alls). Sorry, I don't understand yet. Why isn't the "forall s" in wibble's type a problem? > So it's not easy to see how to spot the bad case and give a better > message. If this comes up again I'll think about it again. Meanwhile, > I'm going to put it under "higher-rank polymorphism gives strange error > message" file. > > Simon -- Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Yet another weakly defined bug report
Yes, getting the right amount of strictness--and in the right places--can be tricky. For your program, it seems you should process each file completely (reflecting its contents strictly in your histogram so the contents can be dropped and the file descriptor closed) before moving on to the next file. This would reduce the number of file descriptors needed to one and limit memory requirements to O(m), where m is the maximum size of a file. In addition, you should process each file incrementally, reducing the memory requirements to O(1). Specific comments follow. "Ketil Z. Malde" wrote: > Dean Herington <[EMAIL PROTECTED]> writes: > > > "Ketil Z. Malde" wrote: > > >> -- | add data from a file to the histogram > >> addFile :: FiniteMap String Int -> String -> IO (FiniteMap String Int) > >> addFile fm name = do > >> x <- readFile name > >> return (addHist fm x) > > I changed this to read x strictly, but it turned out that wasn't quite > enough. See below. Why read a file's contents strictly? What's important is to tabulate its contribution to the histogram strictly. Perhaps return $! addHist fm x might be enough to achieve that (*). > >> -- | add data from all files in a directory to the histogram > >> addDir :: FiniteMap String Int -> String -> IO (FiniteMap String Int) > >> addDir fm dir = do > >> dc <- getDirectoryContents dir > >> fs <- filterM doesFileExist (map ((dir++"/")++) dc) > >> foldM addFile fm fs > > >> addHist :: FiniteMap String Int -> String -> FiniteMap String Int > >> addHist fm = foldl add1 fm . words > >>where add1 f w = case lookupFM f w of > >>Just n -> addToFM f w (n+1) > >>Nothing -> addToFM f w 1 You should do the counting strictly: Just n -> case n+1 of n1 -> addToFM f w n1 Your current limitation on the size of a directory that your program can handle may be due to these unevaluated thunks representing (n+1) calculations. > > The string won't be evaluated until the finite map is demanded. None of the > > code you've shown so far makes that demand. > > [I'll leave my ramblings here, skip to the for the solution] > > Right. But if I do > > f <- addFile emptyFM "foo" > > then no IO should be performed either, right? Right, except that, as Simon M. mentioned, the file is opened so that any opening exceptions are triggered. > And when I later do > > print (head . fmToList f) > > the whole FM needs to be computed, no? Perhaps. You're only demanding the head of the list. Conceivably, the FM logic might be able to determine the lowest key/element pair without evaluating the entire map. > If this is unsound (too lazy) in any way, I don't see it. How much > memory can I expect an FM to consume, anyway? I would expect > something like > > (log n * sizeof(branch node)) + n*sizeof(key+element) > > Which should be roughly equivalent to n*sizeof(key+element), which in > my case (building a frequency count for words) should be roughly > equivalent to the number of different words times their average > length (times 8 bytes per character in a list). Is this far off? > > Experiments show that doing x <- addDir emptyFM on a directory > containing 13Mb of files, the process grows to about 400Mb. > Surprisingly, asking for the head requires a lot more memory and takes > considerable time. > > = > > So, what's really happening? Well, it seems the files were read > strictly, but the FMs weren't constructed yet. So the result was a > lot of files residing in memory, stored as expansive [Char]s. > Changing addFile to: > > > addFile :: FiniteMap String Int -> String -> IO (FiniteMap String Int) > > addFile fm name = do > > h <- openFile name ReadMode > > x <- hGetContents h > > let f = addHist fm x > > hClose (f `seq` h) -- thanks to Peter Thiemann > > return f I find the above approach a bit risky, as you are closing the file after having only shallowly demanded the result of addHist. My earlier suggestion, return $! addHist fm x, makes exactly the same shallow demand, but if that demand is insufficient, loses performance but not correctness. I would recommend letting the runtime system close the file and just being careful to read to end of file before moving on to the next file. > With this, I can at least plough through the 13Mb of files &g
Re: MArray and runST
Keean Schupke wrote:
> Ahh, I see, perhaps you could give me a clue as to why (or how) this
> works...
> I have probably become a little over keen on using '$' as a general
> replacement for
> braces '(' ')' - the '$' was there because the actual wrapper function
> takes arguments and
> it looks neater not to have too many nested braces. I thought this could
> be something to do
> with runST enforcing strictness, but '$!' causes the same problem, only
> runST (wrapper x y z)
> appears to work - if its not too much trouble, how does runSTs type
> enforce this, and why does
> using '$' and '$!' cause type leakage?
Coincidentally, I tripped over this subtlety myself just last night. (I,
too, often use '$' to avoid nested parentheses.) I concluded it was an
instance of the "partial-application restriction" that I found described in
section 7.11.4 of the GHC 5.02 User's Guide (still accessible at the GHC web
site if you look carefully enough).
[Simon: With a few minutes scanning, I couldn't find the same text in the
current online User's Guide. Can you point out where it is?]
-- Dean
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Yet another weakly defined bug report
"Ketil Z. Malde" wrote: > "Simon Marlow" <[EMAIL PROTECTED]> writes: > > > > > -- | add data from a file to the histogram > > > > addFile :: FiniteMap String Int -> String -> IO (FiniteMap > > > String Int) > > > > addFile fm name = do > > > > x <- readFile name > > > > return (addHist fm x) > > > > > > > > -- | add data from all files in a directory to the histogram > > > > addDir :: FiniteMap String Int -> String -> IO (FiniteMap > > > String Int) > > > > addDir fm dir = do > > > > dc <- getDirectoryContents dir > > > > fs <- filterM doesFileExist (map ((dir++"/")++) dc) > > > > foldM addFile fm fs > > > It's not possible to tell from this code whether the readFiles will be > > fully evaluated or not: it depends on how much evaluation addHist does, > > and to what extend the result FiniteMap is demanded, amongst other > > things. > > Of course. Never cut code, I suppose; I thought the parts my > understanding would be weakest would be the monadic stuff, not this: > > > addHist :: FiniteMap String Int -> String -> FiniteMap String Int > > addHist fm = foldl add1 fm . words > >where add1 f w = > > case lookupFM f w of > >Just n -> addToFM f w (n+1) > >Nothing -> addToFM f w 1 > > I felt pretty sure that this would evaluate the string to the end. Am > I wrong? The string won't be evaluated until the finite map is demanded. None of the code you've shown so far makes that demand. -- Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
MonadPlus IO
According to the Haddock documentation for Control.Monad at http://www.haskell.org/ghc/, `IO` is an instance of `MonadPlus`. 1. Where in documentation is this instance described? 2. Where in source code is this instance implemented? 3. Could links to the answers to 1 and 2 be added to the Haddock documentation for Control.Monad? Obviously, these questions apply more generally than just to `MonadPlus IO`. Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Avoiding "No explicit method ..." warnings
George Russell wrote:
> This isn't a bug, just a suggestion. It's not even a very important
> suggestion, but one that might be worth implementing if it's easy and you can
> find the the time. Or perhaps I am just doing things the wrong way?
>
> The point is that I sometimes have something like the following situation
>
> class ComplicatedClass x where
>simpleTitleFn :: x -> String
>muchMoreComplicatedTitleFn :: extra arguments -> x -> IO (WithError (Source blah
>blah blah String)
>
>muchMoreComplicatedTitleFn _ x = [ ... some expression involving simpleTitleFn
>...]
>
> The idea is that only muchMoreComplicatedTitleFn must always work; however instances
>may
> choose to implement it directly, or implement the much simpler function simpleTitleFn
> (if that does all they want).
>
> At the moment the situation is that someone who defines just
>"muchMoreComplicatedTitleFn"
> will get an unnecessary warning message from the compiler about "No explicit method
>or
> default method for simpleTitleFn". I suggest instead introducing a new class of
> optional method (for example, via a pragma {-# OPTIONAL_METHOD simpleTitleFn #-})
>which
> compiles exactly as normal except that (1) no warning is given for instances which
>don't
> define it; (2) a warning is given whenever anyone outside the class declaration
>*uses*
> simpleTitleFn.
This seems to be a lot of mechanism for questionable benefit. A simpler and cleaner
approach, IMHO, is
the following:
class ComplicatedClass x where
complicatedTitleFn :: extra arguments -> x -> IO (WithError (Source blah blah blah
String)
makeComplicatedTitleFn :: (x -> String) -> extra arguments -> x -> IO (WithError
(Source blah blah blah
String)
makeComplicatedTitleFn simpleTitleFn = [ ... some expression involving simpleTitleFn
...]
Each instance either defines complicatedTitleFn directly, or uses
makeComplicatedTitleFn with a simple
title function:
instance ComplicatedClass Foo where
complicatedTitleFn = makeComplicatedTitleFn simpleFooTitleFn
simpleFooTitleFn = ...
Dean
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
Simon Marlow wrote: > > | 2. Calling from foreign code into Haskell to a bound foreign import > > will > > | require some special handling to ensure that a subsequent > > call out to > > | foreign code will use the same native thread. Why couldn't this > > special > > | handling select the same Haskell thread instead of creating > > a new one? > > > > This is just an efficiency issue, right? If creating a > > Haskell thread > > from scratch is very cheap, then it's easier to do that each > > time rather > > than to try to find the carcass of a completed Haskell > > thread. If you > > do the latter, you need to get into carcass management. > > > > But maybe there is more to it than efficiency in your mind? > > To recap, the suggestion was that a Haskell thread which makes a foreign > call, which is turn calls back into Haskell, should use the same Haskell > thread for the callback. So the Haskell thread is not a carcass, it is > still running, but blocked waiting for the result of the foreign call. Yes, exactly. > I'm not sure I've quite got my head around all the implications of doing > this, but it sounds possible. However, I'm not completely convinced > it's desirable: the gain seems to be in efficiency only, and a fairly > small one (creating threads is quite cheap). I imagine you could > demonstrate a performance gain by doing this for an application which > does a lot of callbacks, though. My concern is not for efficiency. (In fact, I assumed the efficiency to be better with the current scheme because it was preferred to the (to me) more natural scheme. In any case, it appears any difference in efficiency--either way--is likely not to be large.) Rather, I find it nonintuitive that calling from Haskell to foreign code and back into Haskell should create a new Haskell thread, when these two Haskell threads really are just different portions of a single "thread of computation" (deliberately vague term). Off the top of my head I can think of two situations in which having separate threads is bothersome. 1. Consider a computation that requires Haskell-side per-thread state and associates it with a thread via the thread's ThreadId. Then some handle to this state currently needs to be passed out to foreign code and then back into Haskell. (This passage could be achieved explicitly as arguments in the call-out and callback, or implicitly in the closure representing the callback.) It is unfortunate that mere inclusion of a foreign call in such a chain of calls necessitates such additional complexity in per-thread state maintenance. 2. It seems perfectly reasonable to want to have the Haskell called-back code throw an exception that is caught by the Haskell code that called out to foreign code. "Reusing" the Haskell thread is necessary (though not sufficient) to achieve such behavior. > The current situation has the advantage of simplicity: > > * for each 'foreign export' we create a single Haskell thread which > lives until completion of the IO action. We can consider a > standalone > program as a call to 'foreign export main :: IO a' from a simple C > wrapper (in fact, that's almost exactly how it works). Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
On 29 Nov 2002, Alastair Reid wrote: > Consider Haskell functions a,b,c,d and C functions A,B,C,D and a call > pattern > > a -> A -> b -> B -> c -> C -> d -> D > > That is, a calls A, calls b, calls B, calls ... > > Suppose we want A,B,C,D executed by the same foreign thread. > > Each of a,b,c,d are executed by different Haskell threads (because a > new Haskell thread is spawned for each call into Haskell) so we have > multiple Haskell threads associated with a single foreign thread. It doesn't feel right to me that a,b,c,d are executed by different Haskell threads. Why shouldn't they all be the *same* Haskell thread? 1. Reasonable exception handling across the Haskell/foreign boundary is not currently supported, but if we imagine moving in that direction, it would seem we'd want a single thread for the given example. 2. Calling from foreign code into Haskell to a bound foreign import will require some special handling to ensure that a subsequent call out to foreign code will use the same native thread. Why couldn't this special handling select the same Haskell thread instead of creating a new one? Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
help for "Killed"
I have a program that dies, saying simply "Killed". How can I tell what that means? I presume the program is suffering a ThreadKilled exception, and I guess it may be due to stack or heap overflow. (The program is processing a 50MB file.) Profiling, even with -xc, yields no information. Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
On 26 Nov 2002, Alastair Reid wrote: > > Umm, Alastair, I think you've got things a bit mixed up here. Did > > you mean two ways to create a native thread? > > No. > > > There are currently three ways to create a Haskell thread (forkIO, > > foreign export, finalizers) and Wolfgang has proposed a fourth > > (forkNativeThread). Invocation of a signal handler also creates a Haskell thread, doesn't it? > I was (implicitly) viewing forkIO and forkNativeThread as two variants > of the same operation. Both fork a Haskell thread, one of them also > creates a native thread. (It may also choose to use the native thread > as the Haskell thread but that's not externally observable.) > > I was putting off finalizers until the end. > > >> 1) forkNativeThread :: IO () -> IO () > >> > >> The fresh Haskell thread is associated with a fresh native thread. > >> > >> (ToDo: do we really need to use a fresh native thread or would a > >> pool of threads be ok? The issue could be avoided by separating > >> creation of the native thread from the 'associate' operation.) > >> > >> 2) Calls to a threadsafe foreign export allocate a fresh Haskell > >> thread which is then associated with the Haskell thread. > > > I don't know what you mean by a "threadsafe foreign export". Did > > you mean "threadsafe foreign import" perhaps? And I'm not sure how > > a fresh Haskell thread is associated with a Haskell thread ;-) > > Using the bound/free terminology suggested by Seth, what I meant was > "bound foreign import". Actually, I proposed the terms, and Seth criticized the proposal. Perhaps "bound" and "unbound" might be a bit better and partially avoid the possible confusion with lambda calculus variables. > >> [ToDo: can Haskell threads with no associated thread make foreign > >> calls using a thread associated with some other thread? > > > er... overloading the word "thread" was maybe not such a good idea. > > I think you're asking whether a green thread can grab a native > > thread to make a foreign call. The current answer is no... but can > > you think of a reason we might want this feature? > > My question was of the form: 'is a correct implementation allowed to > use a native thread even if the programmer didn't ask for it?' not > 'can we make this happen?' > > Sorry for all the confusion, here's the key part of the proposal again > - hopefully without the ambiguity. > > > Haskell threads may be bound with either zero or one native threads. > Binding occurs at thread creation time. There are four ways to > create Haskell threads so there are four cases to consider: How about: A Haskell thread may be bound to a native thread. Such binding occurs when the Haskell thread is created and persists for the lifetime of the Haskell thread. A Haskell thread that is not bound to a native thread is called "unbound". There are four ways ... > 1) forkNativeThread :: IO () -> IO () > The fresh Haskell thread is bound to a fresh native thread. > > 2) forkIO :: IO () -> IO () > The fresh Haskell thread is not bound to a native thread. > > 3) Calls to a bound foreign export allocate a fresh Haskell > thread which is then bound to the calling thread thread. "... which is bound to the calling native thread" ? > Bound foreign exports have the form > >foreign export bound foo :: > > and otherwise behave like normal foreign exports. > > 4) ToDo: For completeness, there ought to be a way to 'bind' > finalizers to native threads but no concrete proposal currently > exists. > > [ToDo: The following could be simplified by saying that all foreign > calls are performed by the bound thread if one exists and eliminate > the concept of 'bound foreign imports'. The only reason to allow > any flexibility is to allow for faster implementations.] > Calls to bound foreign imports by threads which are bound to a > native thread are performed by that native thread. > > Bound foreign imports have the form > >foreign import bound foo :: > > and otherwise behave like normal foreign imports. > > Calls to any free (i.e., not bound) foreign imports may be made in > the bound thread (if it exists) or by some other native thread at > the implementation's discretion. > > > -- > Alastair ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
On 26 Nov 2002, Alastair Reid wrote: > ps Better names than 'native' and 'green' surely exist. Something > which conveys the idea that the thread will be remembered for later > use seems appropriate but no good words spring to mind. Perhaps "bound" and "free"? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
Simon Marlow wrote: > > Simon Marlow: > > > [Lazy I/O] is nice, but it introduces too many problems. What > > > happens to any I/O errors encountered by the lazy I/O? They have to > > > be discarded, which means you can't effectively use lazy I/O for > > > robust applications anyway. > > > > Surely they are thrown as exceptions which can then be manipulated > > in pure code using > > > > mapExceptions :: (Exception -> Exception) -> (a -> a) > > > > and caught in the IO monad using catch? > > No, the report clearly states that they are discarded. Could you please point out where? I couldn't find it with a quick look. > We could perhaps have our own versions of the lazy I/O operations which > throw exceptions, but this in itself is problematic because these kind > of exceptions would be asynchronous in nature. If lazy I/O is allowed > to raise exceptions, then we have a situation where evaluating anything > can raise an I/O exception. In theory this shouldn't be a problem - we > all ought to be writing asynchronous-excpetion-safe code anyway to > protect against StackOverflow, but an I/O exception is often one that > you want to handle gracefully and recover from. I feel distinctly > uncomfortable about I/O exceptions being thrown by pure code, and even > more uncomfortable about asynchronous I/O exceptions. Is even the following example from the library report (section 11.8.2) problematic? import System import Char( toUpper ) main = do [f1,f2] <- getArgs s <- readFile f1 writeFile f2 (map toUpper s) -- Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: re-opening a closed stdin?
Bernard James POPE wrote: > [Dean wrote:] > Wouldn't you want the debugger to use stdin and stdout for its > interaction with the > > user, and run the object program with stdin and stdout handles of its own > > creation? (In that case your question seems moot.) I've always been very confused > > by debuggers that try to share stdin/stdout with the debugged program. > > Dean > > Hi Dean, > > You make a good point. > > One thing to note is that in my debugger the user's program is run to > completion before debugging begins. This means that the debugger does not need > to use stdin/stdout until after the user's program is finished with them. > > In a debugger that intersperses its own I/O with that of the user's program, > it would make a lot of sense to do as you say above. > > I (perhaps naively) thought that it would be simpler for my debugger to > reuse the stdin/stdout handles. > > Were you thinking of using a system call to dup, or something else. > > I am not a terminal expert, as you can probably guess, so > I'd appreciate any comments that you feel are appropriate. > > Thanks, > Bernie. Glynn Clements mentioned some good reasons why you shouldn't try to "reuse" stdin and stdout. For example, stdin or stdout (or both) could be connected to files, pipes, etc. If your debugger truly runs the user program to completion, there shouldn't be any problem: The operating system "reuses" "terminal"-connected stdin/stdout when a subprocess completes. So I suspect you need the user program process to stick around for post-"completion" debugging. In this case I still think the clean approach is to have the debugger create fresh stdin/stdout handles for execution of the user program. When the user program does want to do "terminal" input and/or output, on Unix I would first consider pseudo-terminals (man pty). Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [HOpenGL] HOpenGL and --enable-threaded-rts
Let me ask a naive question concerning the implementation of threading in the GHC RTS. Would it be feasible to support an alternative strategy for mapping Haskell threads onto OS threads, namely that the two sets are kept in one-to-one correspondence? The thread multiplexing and migration that GHC now supports sounds very cool, but it seems to violate assumptions of potentially many threaded libraries. If the 1-1 model is as straightforward as it seems it should be, it might not be too complicated to support both. The 1-1 model could be selected for the entire process, or preferably for each thread on its creation, if this is feasible. An aside about performance: It seems the reason for thread multiplexing and migration is performance, to allow Haskell threads to be lighter weight than their OS counterparts. While I agree with this point, there have been, perhaps are, and most probably will be threading systems where OS threads are light enough in weight to support the 1-1 model with good performance. So I don't think that concern over performance is by itself enough to invalidate the usefulness of the 1-1 model. Dean Simon Marlow wrote: > There are two problems with this approach, I think. The situation is > like this (correct me if I'm wrong): > > - Haskell thread H1 running on OS thread O1 registers a > callback C. > > - Haskell thread H1/O1 makes a blocking call into HOpenGL. > This call is made also in O1. The RTS allocates another > OS worker thread O2, and continues running Haskell threads. > > - HOpenGL, running in O1, invokes the callback C. The RTS > stops O1, creates a new Haskell thread H2 in which to run C, > and eventually runs H2 in O2. > > Problem #1 is the call-in: our current implementation *always* runs the > callback in a different OS thread from the calling thread. It was > simpler this way, but perhaps this can change. > > Problem #2 is that we would have to add some extra machinery to > guarantee that a given Haskell thread executes in a particular OS > thread, and somehow do it in a way that was "fair" (i.e. the Haskell > thread with a preference for its OS thread doesn't get starved, and > doesn't starve other threads). The RTS currently doesn't make any > distinction between OS threads; a given Haskell thread can even migrate > from one OS thread to another during its execution. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
multiple processes and threads
I have an application that uses multiple processes and multiple threads together. What's the best way to detect child process terminations? The initial thread in the inital process serves as driver of the application. It creates child processes and threads to carry out portions of the computation. A natural way to have the driver detect termination of these child processes and threads would be to have the driver "listen" on a single MVar to which termination notices are "posted". Child threads would simply post their termination notices directly. For child processes, I'd like to have a single thread in the initial process execute (getAnyProcessStatus True False) repeatedly, posting a termination notice each time such a call returns. However, with the current implementation of Concurrent Haskell, when the thread pends on the getAnyProcessStatus call, the entire initial process pends. The best solution I've come up with so far, which is unsatisfying, is to have this thread poll periodically (that is, loop over (getAnyProcessStatus False False) and (threadDelay)). Is there a better way? Dean Herington ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
inscrutable warning
Can someone explain the following warning? --- module Warning where type A = IO () class CA t where a :: t -> A instance CA () where a = return instance (CA t) => CA (IO t) where a = (>>= a) data B = B A class CB t where b :: t -> B instance (CA t) => CB (IO t) where b = B . a --- % ghci Warning.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Compiling Warning ( Warning.hs, interpreted ) WARNING: ignoring polymorphic case in interpreted mode. Possibly due to strict polymorphic/functional constructor args. Your program may leak space unexpectedly. Ok, modules loaded: Warning. Warning> ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: OPTIONS in a literate source file
Thanks, that did it.
Did I miss this subtlety in the documentation, or should it be added
there?
Dean
On Mon, 21 Jan 2002, Sigbjorn Finne wrote:
> Try
>
> >{-# OPTIONS -fglasgow-exts #-}
>
> i.e., no space between '>' and '{'.
>
> --sigbjorn
>
> - Original Message -
> From: "Dean Herington" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, January 21, 2002 17:26
> Subject: OPTIONS in a literate source file
>
>
> > I can't figure out how to get GHC to recognize my OPTIONS pragmas in a
> > literate source file. Neither
> >
> > > {-# OPTIONS -fglasgow-exts #-}
> >
> > nor
> >
> > {-# OPTIONS -fglasgow-exts #-}
> >
> > works as the first line in the file. Can anybody tell me what I'm doing
> > wrong?
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
OPTIONS in a literate source file
I can't figure out how to get GHC to recognize my OPTIONS pragmas in a
literate source file. Neither
> {-# OPTIONS -fglasgow-exts #-}
nor
{-# OPTIONS -fglasgow-exts #-}
works as the first line in the file. Can anybody tell me what I'm doing
wrong?
Thanks.
--Dean
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: multithreading with multiprocessing (Was: Concurrent and Posix libraries...)
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Poll: scope in GHCi
A minor suggestion: Let ":m *M" apply to compiled modules as well as interpreted. In other words, ":m +M" requests all top-level entities (accepting only exported ones for compiled modules) while ":m *M" requests only exported entities (whether the module is compiled or interpreted). More generally, though, I dislike allying the "all / exported only" choice with the "add a module to the scope" command; they should be specified independently. In particular, one should be able to make the choice for each of the modules in the ":m M1..Mn" command. (Otherwise, how can one reasonably request a scope consisting of only the exported entities from a single interpreted module?) A question: What is the syntax of the "M1..Mn" form? I like Koen Claessen's suggestion that one be able to request all top-level names from a compiled module. Here's a variant of Simon's proposal that addresses the above concerns: * Let a be either the name of a module (implying the set of all top-level names in that module) or a square-bracketed, space-separated list of module names (implying the set of names exported from the modules). * Let a be a list of s. Whitespace must separate adjacent s when neither is in square brackets. * Let the ":module" command take an optional '+' or '-' followed by a . '+' indicates additions to the scope; '-' indicates subtractions from the scope; absence of both indicates redefinition of the scope. Square bracketing is suggested for indicating that only exported names are desired, to match the prompt syntax. An alternative for both would be to prefix each such module name by, say, '*'. Examples of these two alternatives: Main[IO]> :module + [Char Monad] Foo Main Foo[IO Char Monad]> or Main *IO> :module + *Char *Monad Foo Main *IO *Char *Monad Foo> I think I prefer the latter. Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
multithreading with multiprocessing (Was: Concurrent and Posix libraries...)
`forkProcess` creates an exact copy of the calling process, except for the return value from `forkProcess` that allows for discriminating the parent from the child. In your example, there are two active threads at the time `forkProcess` is done, so the new process has (copies of) the same two active threads. Then the race is on in the new process: depending on the (unspecified) order of execution, the copy of the initial thread may get to the `print` before its sibling thread gets to do `executeFile` (which wipes away both existing threads). 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? Dean Herington Marcus Shawcroft wrote: > Hi, > > I want to use a thread in concurrent haskell to manage a posix > fork/exec/wait. I expected the test code attached below to output > "recovering result" once, instead I get "recovering result" twice. Can > anyone shed some light on whats going wrong? > > (ghci 5.02.1 x86 linux) > > Thanks > /Marcus > > > module Test where > > > import Concurrent > > import Posix > > > main = do > > mv <- newEmptyMVar > > forkIO $ do x <- forkProcess > > case x of > > Nothing -> do > > executeFile "sleep" True ["2"] Nothing > > error "oops" > > Just pid -> > > getProcessStatus True False pid > > putMVar mv () > > print "recovering result" > > takeMVar mv ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
posix library for Windows?
Is the posix library (-package posix) supposed to be supported on Windows? If not (as I expect to have confirmed), what are the alternatives for process control on Windows? Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
