RE: how to determine a programs memory usage at runtime?
On 22 June 2004 03:51, Bernard James POPE wrote: The mblocks_allocated variable should give me what I want. I think having access to this would also be useful to people who are profiling their programs. You see a few papers where people want to report how much memory their application needs, and having a high-water mark is usually good enough. Beats trying to get the information from top. Note that this only counts memory allocated by the GHC storage manager; it doesn't include the data segments, malloc(), the C stack, or other mmap()'d stuff. Be careful if your program is using any of these other allocation methods (perhaps via an external library through the FFI). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to determine a programs memory usage at runtime?
On Tue, Jun 22, 2004 at 09:27:40AM +0100, Simon Marlow wrote: On 22 June 2004 03:51, Bernard James POPE wrote: The mblocks_allocated variable should give me what I want. I think having access to this would also be useful to people who are profiling their programs. You see a few papers where people want to report how much memory their application needs, and having a high-water mark is usually good enough. Beats trying to get the information from top. Note that this only counts memory allocated by the GHC storage manager; it doesn't include the data segments, malloc(), the C stack, or other mmap()'d stuff. Be careful if your program is using any of these other allocation methods (perhaps via an external library through the FFI). Ah, that's a good point. I didn't think of that. For what it is worth I've put a simple Haskell wrapper to mblocks_allocated on the web. It provides this function: megaBytesAllocated :: IO Integer On my simple tests it seems reliable, when compared to what top says. I've put it here in case anyone wants to use it: http://www.cs.mu.oz.au/~bjpop/code.html Cheers, Bernie. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to determine a programs memory usage at runtime?
On Tue, Jun 22, 2004 at 09:27:40AM +0100, Simon Marlow wrote: On 22 June 2004 03:51, Bernard James POPE wrote: The mblocks_allocated variable should give me what I want. I think having access to this would also be useful to people who are profiling their programs. You see a few papers where people want to report how much memory their application needs, and having a high-water mark is usually good enough. Beats trying to get the information from top. Note that this only counts memory allocated by the GHC storage manager; it doesn't include the data segments, malloc(), the C stack, or other mmap()'d stuff. Be careful if your program is using any of these other allocation methods (perhaps via an external library through the FFI). Might it be worthwhile adding to the foreignPtr interface a way of telling the RTS how much memory that foreignPtr actually uses? It might be useable in an advisory sense in deciding which garbage to collect, or just in an informational sense (as here), when one wants to see how much memory is used (or, for example, when profiling). One could also add an extra user flag, so perhaps when profiling memory usage one could look at only mmapped memory usage, or something like that. The user flag could perhaps be ignored when compiling without profiling... -- David Roundy http://www.abridgegame.org ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can you block a thread in GHC by its threadID?
On Tue, Jun 22, 2004 at 10:37:54AM +0200, Volker Stolz wrote: In local.glasgow-haskell-users, you wrote: Ideally I'd like this function: blockThread :: ThreadId - IO () unBlockThread :: ThreadId - IO () I should have some bit-rotted patches here for freezeThread :: ThreadId - IO () thawThread :: ThreadId - IO () and a new PrimOp which allows you to set the next thread to run (at a first glance, at least I could find the patch for the latter). If you could find them that would be great. Cheers, Bernie. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can you block a thread in GHC by its threadID?
On Tue, Jun 22, 2004 at 09:45:48AM +0100, Simon Marlow wrote:
On 22 June 2004 06:11, Bernard James POPE wrote:
Ideally I'd like this function:
blockThread :: ThreadId - IO ()
and thus:
unBlockThread :: ThreadId - IO ()
Hmm, might be possible. Can the blocked thread be woken up by an
exception? (this is usually the case for blocked threads).
I guess so.
Note that if you block a thread and then drop all references to it, the
garbage collector will wake up the thread with a BlockedOnDeadMVar
exception.
That sounds reasonable.
I think I'd be tempted to call these functions {stop,continue}Thread to
avoid overloading the block/unblock terms any more. Stop/continue is
used in Unix land too.
Yes, those names are fine (I was thinking of suspend/resume).
To implement this you'll need another StgTSOBlockReason state for
stopped threads. Stopping already blocked threads might not be a
problem, since (in some cases at least) the blocking operation will be
retried when the thread is started again. I'm not sure whether this is
always the case though.
Stopping a thread blocked on a foreign call
cannot be done. Stopping a thread blocked on I/O or delay# will need to
remove the thread from the appropriate queue.
You'll need two new primops: stopThread#, continueThread#. Take a look
at the implementation of killThread# for clues (in
ghc/rts/Exception.hc). Don't forget to take into account the case when
a thread stops itself (that's the tricky one).
Hmm. In the worst case I can just ban it by comparing the
threadIds, and require the use of yield?
Let us know if you need any more guidance...
Thanks. I'll start looking into it in more detail.
Supposing that such a thing is indeed possible is there any chance that
it could be folded into GHC? (Then I wouldn't have to ship my own variant
of the runtime with buddha.)
Cheers,
Bernie.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: can you block a thread in GHC by its threadID?
On 22 June 2004 10:39, Bernard James POPE wrote: Supposing that such a thing is indeed possible is there any chance that it could be folded into GHC? (Then I wouldn't have to ship my own variant of the runtime with buddha.) Certainly, I don't see any reason why not. It looks like a bolt-on extension rather than a global change. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can you block a thread in GHC by its threadID?
In local.glasgow-haskell-users, you wrote: On 22 June 2004 10:39, Bernard James POPE wrote: Supposing that such a thing is indeed possible is there any chance that it could be folded into GHC? (Then I wouldn't have to ship my own variant of the runtime with buddha.) Certainly, I don't see any reason why not. It looks like a bolt-on extension rather than a global change. A similar feature has been *removed* from Java recently for a good reason (rule of thumb: If you used it, you did something wrong). OTOH I see that it's handy for debuggers. -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME Neu! Ändern Sie den Anfangstag Ihrer Woche ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Understanding strictness of ghc output
Hello, I'm trying to figure out how you tell if ghc has correctly infered strictness or whether or not a little more prompting from me is needed. I tried compiling with -ddump-simpl, and I guess from looking at this the DmdType bit is what I want (maybe). So if I have DmdType LS for a function of arity 2, does this mean the function is lazy in the first argument and strict in the second? I would be pretty confident that this was the correct interpretation, but this is the Haskell code (from AVL library).. height :: AVL e - Int height = addHeight 0 where addHeight h E= h addHeight h (N l _ _) = addHeight h+2 l addHeight h (Z l _ _) = addHeight h+1 l addHeight h (P _ _ r) = addHeight h+2 r It seems pretty obvious to me that addHeight is strict in its first argument if + is strict for Ints (as I guess it is). But this gives DmdType LS. Even if I rewrite it.. height :: AVL e - Int height = addHeight 0 where addHeight h E= h addHeight h (N l _ _) = let h' = h+2 in h' `seq` addHeight h' l addHeight h (Z l _ _) = let h' = h+1 in h' `seq` addHeight h' l addHeight h (P _ _ r) = let h' = h+2 in h' `seq` addHeight h' r .. it still gives DmdType LS. So does this.. height :: AVL e - Int height = addHeight 0 where addHeight h E= h addHeight h (N l _ _) = h `seq` addHeight (h+2) l addHeight h (Z l _ _) = h `seq` addHeight (h+1) l addHeight h (P _ _ r) = h `seq` addHeight (h+2) r So am I interpreting core correctly? Thanks -- Adrian Hey ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Understanding strictness of ghc output
On 22 June 2004 13:30, Adrian Hey wrote: I'm trying to figure out how you tell if ghc has correctly infered strictness or whether or not a little more prompting from me is needed. I tried compiling with -ddump-simpl, and I guess from looking at this the DmdType bit is what I want (maybe). So if I have DmdType LS for a function of arity 2, does this mean the function is lazy in the first argument and strict in the second? I would be pretty confident that this was the correct interpretation, but this is the Haskell code (from AVL library).. height :: AVL e - Int height = addHeight 0 where addHeight h E= h addHeight h (N l _ _) = addHeight h+2 l addHeight h (Z l _ _) = addHeight h+1 l addHeight h (P _ _ r) = addHeight h+2 r It seems pretty obvious to me that addHeight is strict in its first argument if + is strict for Ints (as I guess it is). But this gives DmdType LS. Could you post the actual Core? I agree that addHeight looks strict in its first argument. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
Adrian Hey [EMAIL PROTECTED] writes: height :: AVL e - Int height = addHeight 0 where addHeight h E= h addHeight h (N l _ _) = addHeight h+2 l addHeight h (Z l _ _) = addHeight h+1 l addHeight h (P _ _ r) = addHeight h+2 r It seems pretty obvious to me that addHeight is strict in its first argument if + is strict for Ints (as I guess it is). No, this looks very obviously lazy to me. The first argument is always a pattern variable, h, and therefore no evaluation is required on it - the value is just bound lazily and used on the RHS. height :: AVL e - Int height = addHeight 0 where addHeight h E= h addHeight h (N l _ _) = let h' = h+2 in h' `seq` addHeight h' l addHeight h (Z l _ _) = let h' = h+1 in h' `seq` addHeight h' l addHeight h (P _ _ r) = let h' = h+2 in h' `seq` addHeight h' r .. it still gives DmdType LS. Even though many uses of 'h' are strictified, the first clause addHeight h E= h is still lazy, because it simply binds the variable without forcing it. height :: AVL e - Int height = addHeight 0 where addHeight h E= h addHeight h (N l _ _) = h `seq` addHeight (h+2) l addHeight h (Z l _ _) = h `seq` addHeight (h+1) l addHeight h (P _ _ r) = h `seq` addHeight (h+2) r Same again. Try addHeight h E= h `seq` h which, although it looks bizarre, actually forces the evaluation of h, whilst simply returning it does not. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
On Tue, Jun 22, 2004 at 01:52:44PM +0100, Malcolm Wallace wrote: Adrian Hey [EMAIL PROTECTED] writes: [...] the first clause addHeight h E= h is still lazy, because it simply binds the variable without forcing it. Since addHeight _|_ E - _|_, this is strict in the first argument. I do not know, what the strictness analyzer makes of it, though. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. pgp1oAogFYQMJ.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
On Tue, Jun 22, 2004 at 01:52:44PM +0100, Malcolm Wallace wrote: Same again. Try addHeight h E= h `seq` h which, although it looks bizarre, actually forces the evaluation of h, whilst simply returning it does not. That contradicts my intution for seq. I would read it as h is forced before h is forced, and I would think that (h `seq` h) is equivalent to h. Were I am wrong? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
Simon Peyton-Jones [EMAIL PROTECTED] writes: | That contradicts my intution for seq. I would read it as h is forced | before h is forced, and I would think that (h `seq` h) is equivalent | to h. | | Were I am wrong? You're not wrong -- Malcolm is. The function is certainly strict in h, and GHC finds it. Well, it is certainly the case that in a denotational sense the function is strict in h, because if h is bottom, the result is bottom. But my operational understanding is that h is a projection, that is, it is passed from argument to result unmodified. The demand on h comes from the caller of the present function, which may or may not be strict in that result. Thus, the function code itself here does not force the evaluation of h. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Understanding strictness of ghc output
| Well, it is certainly the case that in a denotational sense the | function is strict in h, because if h is bottom, the result is bottom. Right. And GHC's operational behaviour is faithful to the denotational semantics. When GHC compiles the program, if h is bottom, the call will not return. Simon | | But my operational understanding is that h is a projection, that is, | it is passed from argument to result unmodified. The demand on h | comes from the caller of the present function, which may or may not | be strict in that result. Thus, the function code itself here does | not force the evaluation of h. | | Regards, | Malcolm | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
On Tue, Jun 22, 2004 at 02:37:38PM +0100, Malcolm Wallace wrote: Simon Peyton-Jones [EMAIL PROTECTED] writes: | That contradicts my intution for seq. I would read it as h is forced | before h is forced, and I would think that (h `seq` h) is equivalent | to h. | | Were I am wrong? You're not wrong -- Malcolm is. The function is certainly strict in h, and GHC finds it. Well, it is certainly the case that in a denotational sense the function is strict in h, because if h is bottom, the result is bottom. But my operational understanding is that h is a projection, that is, it is passed from argument to result unmodified. The demand on h comes from the caller of the present function, which may or may not be strict in that result. Thus, the function code itself here does not force the evaluation of h. The point is that, because the function is strict, its implementation may force the evaluation of h, if it so chooses. This is up to the compiler, and as Simon pointed out, it actually does force h when compiling with optimization. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. pgphES3Jc78mU.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
On Tue, 2004-06-22 at 14:17, Tomasz Zielonka wrote: On Tue, Jun 22, 2004 at 01:52:44PM +0100, Malcolm Wallace wrote: Same again. Try addHeight h E= h `seq` h which, although it looks bizarre, actually forces the evaluation of h, whilst simply returning it does not. That contradicts my intution for seq. I would read it as h is forced before h is forced, and I would think that (h `seq` h) is equivalent to h. I think a better intuition is that h is forced before h is *returned*. You can return a value without that value being forced to head normal form. In fact this is the ordinary case. Values are only 'forced' when you pattern match on them (or if you use seq), and even then only when the result of the pattern match is used. Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Understanding strictness of ghc output
On 22 June 2004 15:11, Duncan Coutts wrote: On Tue, 2004-06-22 at 14:17, Tomasz Zielonka wrote: On Tue, Jun 22, 2004 at 01:52:44PM +0100, Malcolm Wallace wrote: Same again. Try addHeight h E= h `seq` h which, although it looks bizarre, actually forces the evaluation of h, whilst simply returning it does not. That contradicts my intution for seq. I would read it as h is forced before h is forced, and I would think that (h `seq` h) is equivalent to h. I think a better intuition is that h is forced before h is *returned*. You can return a value without that value being forced to head normal form. In fact this is the ordinary case. Values are only 'forced' when you pattern match on them (or if you use seq), and even then only when the result of the pattern match is used. Nope. You can't return something without evaluating it to head normal form in Haskell. Every value that is returned is a value, never a thunk. If you want to return something unevaluated, you have to wrap it in a constructor. h `seq` h is the same as h. addHeight is strict in h, no seq is necessary. If there's a Haskell implementation that compiles addHeight in such a way that addHeight _|_ e /= _|_, then I'd say it was wrong (but we don't have an official denotational semantics for Haskell, only an informal agreement ;-). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
On Tue, Jun 22, 2004 at 03:37:01PM +0100, Simon Marlow wrote: If there's a Haskell implementation that compiles addHeight in such a way that addHeight _|_ e /= _|_, then I'd say it was wrong (but we don't have an official denotational semantics for Haskell, only an informal agreement ;-). As long as the implementation would not do anything very fishy to produce a non-monotonic function, if addHeight _|_ e = m for some integer m, then addHeight n e would have to be m for all n, and I would agree very much that this is wrong :-) Greetings, Carsten P.S.: Is there a special reason for the Simons on this list not to produce messages with proper References headers? *duck* -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. pgphSFvSaiEu2.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
Simon Marlow [EMAIL PROTECTED] writes: Nope. You can't return something without evaluating it to head normal form in Haskell. Every value that is returned is a value, never a thunk. If you want to return something unevaluated, you have to wrap it in a constructor. Actually, there are two possible strategies for who evaluates a thunk to head normal form. The caller or the callee. GHC says that the callee always evaluates to HNF before returning the value. But the language does not force this implementation choice. It is equally possible for an implementation of the function to return a thunk and for the caller to evaluate it if necessary. Both strategies give the same result semantically, since if the value in question is demanded, it gets evaluated. If there's a Haskell implementation that compiles addHeight in such a way that addHeight _|_ e /= _|_, then I'd say it was wrong So would we all! Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
On Tue, Jun 22, 2004 at 02:28:21PM +0100, Simon Peyton-Jones wrote: | That contradicts my intution for seq. I would read it as h is forced | before h is forced, and I would think that (h `seq` h) is equivalent | to h. | | Were I am wrong? You're not wrong -- Malcolm is. The function is certainly strict in h, and GHC finds it. I will only add that I am aware that my wording is imprecise. It's more like Forcing (a `seq` b) forces a, then forces b, and then returns the value of b, unless a is bottom or b is bottom - in which case it returns bottom. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Understanding strictness of ghc output
On 22 June 2004 15:59, Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] writes: Nope. You can't return something without evaluating it to head normal form in Haskell. Every value that is returned is a value, never a thunk. If you want to return something unevaluated, you have to wrap it in a constructor. Actually, there are two possible strategies for who evaluates a thunk to head normal form. The caller or the callee. GHC says that the callee always evaluates to HNF before returning the value. But the language does not force this implementation choice. It is equally possible for an implementation of the function to return a thunk and for the caller to evaluate it if necessary. Both strategies give the same result semantically, since if the value in question is demanded, it gets evaluated. If a function is called, then the result has been demanded. There are no situations in which a function has been called but the caller will accept a thunk as the result without further evaluating it. So what is the advantage of returning a possibly-unevaluated result? The caller will definitely have to evaluate it, so every eval will need to loop until the value is in HNF. And what about updates? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
On Tuesday 22 Jun 2004 2:28 pm, Simon Peyton-Jones wrote: The DmdType for the Int# is indeed L but that's irrelevant because Int# values are always evaluated. The demand info is always L for an unboxed type. Thanks, I had noticed it did appear to have decided h was unboxed (assuming my interpretation of core was correct), so it seemed rather strange that addHeight could be lazy (non-strict) in that argument. So does L mean Lazy, or something else? Thanks -- Adrian Hey ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Understanding strictness of ghc output
it means Lazy, but it's misleading for unboxed types | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Adrian Hey | Sent: 22 June 2004 17:09 | To: [EMAIL PROTECTED] | Subject: Re: Understanding strictness of ghc output | | On Tuesday 22 Jun 2004 2:28 pm, Simon Peyton-Jones wrote: | The DmdType for the Int# is indeed L but that's irrelevant because | Int# values are always evaluated. The demand info is always L for an | unboxed type. | | Thanks, I had noticed it did appear to have decided h was unboxed | (assuming my interpretation of core was correct), so it seemed rather | strange that addHeight could be lazy (non-strict) in that argument. | | So does L mean Lazy, or something else? | | Thanks | -- | Adrian Hey | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding strictness of ghc output
Simon Marlow [EMAIL PROTECTED] writes: If a function is called, then the result has been demanded. There are no situations in which a function has been called but the caller will accept a thunk as the result without further evaluating it. The caller would definitely have to evaluate it, so every eval will need to loop until the value is in HNF. Indeed. So what we are talking about is a peephole optimisation, where the callee can save some work for the system overall by evaluating its result to HNF, rather than leaving it to the caller to loop and test on every iteration. So what is the advantage of returning a possibly-unevaluated result? There is no operational advantage. The results are indistinguishable except in performance terms. My only, rather trivial, point is that the close visual similarity of f x = x and f (C x) = (C x) means that one can /explain/ both cases in identical terms, namely that the value bound by the variable x is potentially not-yet-evaluated, and that function f builds its result without looking at the value of x. And if you implement the language naively, it even works! Just slower than it might be. And what about updates? What do you mean? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Lazy version of peekArray
Hi, I'm trying to make use of memory mapped files with Haskell. It is kind of fun, I managed to mmap a file (actualy CreateFileMapping, because I'm on a Windows box), managed to setup finalizers (those kind of work now, see my posts about finalizers and FFI). Now I got to content... and here is the problem. Data I want to read is large, mostly binary with parts that must be parsed. But peekArray is not lazy (is IO action), produces large lists in strict mode. So I had to write my own thing. Provided that underlying data does not change following unsafeLazyPeekArray and friends should be good. Does anybody see any problems in following code? Maybe there is something obvious I do not see... Those functions were designed to be list less, when used in producer consumer fashion list will not be generated (I hope). Is current state GHC compiler smart enough to optimize this efficiently? How can I help it with this task (maybe a pragma here and there?) Anyway, the code. Maybe someone find it interesting: unsafeLazyPeekArray size ptr = unsafeLazyPeekArrayOffset 0 size ptr unsafeLazyPeekArrayOffset :: Storable a = Int - Int - ForeignPtr a - [a] unsafeLazyPeekArrayOffset offset size ptr | size = 0 = [] | otherwise = unsafePerformIO $ helper offset where helper index | index = size = return [] | otherwise = unsafeInterleaveIO $ do x - withForeignPtr ptr (\xptr - peekElemOff xptr index) xs - helper (index+1) return (x:xs) unsafeLazyPeekArrayOffset0 :: (Storable a, Eq a) = Int - a - ForeignPtr a - [a] unsafeLazyPeekArrayOffset0 offset marker ptr = unsafePerformIO $ helper offset where helper index = unsafeInterleaveIO $ do x - withForeignPtr ptr (\xptr - peekElemOff xptr index) if x==marker then return [] else do xs - helper (index+1) return (x:xs) unsafeLazyPeekArray0 :: (Storable a, Eq a) = a - ForeignPtr a - [a] unsafeLazyPeekArray0 marker ptr = unsafeLazyPeekArrayOffset0 0 marker ptr -- Pozdrawiam, Regards, Gracjan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ObjectIO
Hi, In the following code only processInit and processClose get ever called, other callbacks are *never* invoked. Is this known problem? Do I miss something obvious? How do I get the handle of main window? Here is the code: module Main where import Graphics.UI.ObjectIO processAttributes = [ ProcessActivate processActivate , ProcessDeactivate processDeactivate , ProcessClose processClose , ProcessOpenFiles processOpenFiles -- , ProcessWindowPos ItemPos -- , ProcessWindowSize Size , ProcessWindowResize processWindowResize --, ProcessToolbar [ToolbarItem ps] -- , ProcessNoWindowMenu ] processInit ps = do liftIO $ putStrLn processInit return ps processActivate ps = do liftIO $ putStrLn processActivate return ps processDeactivate ps = do liftIO $ putStrLn processDeactivate return ps processClose ps = do liftIO $ putStrLn processClose closeProcess ps processOpenFiles files ps = do liftIO $ putStrLn (processOpenFiles ++ show files) return ps processWindowResize oldsize newsize ps = do liftIO $ putStrLn (processWindowResize ++ show newsize) return ps main = do startIO SDI () processInit processAttributes -- Pozdrawiam, Regards, Gracjan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ObjectIO
Gracjan Polak wrote: Hi, In the following code only processInit and processClose get ever called, other callbacks are *never* invoked. Is this known problem? Do I miss something obvious? Forgotten: Windows 2000, GHC-6.2.1 :) -- Pozdrawiam, Regards, Gracjan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
