Re: Way to expose BLACKHOLES through an API?
Hi, On 16.11.2011, at 10:43, Duncan Coutts wrote: On Tue, 2011-11-08 at 15:43 +, Simon Marlow wrote: Hmm, but there is something you could do. Suppose a thread could be in a mode in which instead of blocking on a BLACKHOLE it would just throw an asynchronous exception WouldBlock. Any computation in progress would be safely abandoned via the usual asynchronous exception mechanism, and you could catch the exception to implement your evaluateNonBlocking operation. I'm not sure this would actually be useful in practice, but it's certainly doable. The linux kernel folks have been discussing a similar idea on and off for the last few years. The idea is to return in another thread if the initial system call blocks. Perhaps there's an equivalent here. We have an evaluateThingy function and when the scheduler notices that thread is going to block for some reason (either any reason or some specific reason) we return from evaluateThingy with some info about the blocked thread. The thing that the kernel folks could never decide on was to do with thread identity: if it was the original thread that blocked and we return in a new thread, or if the original thread returns and a clone is the one that blocks. The difference between the requirements of the Linux kernel folks and the OP is that in the Linux kernel the evaluation has to continue, while in the Haskell case we know that the BLACKHOLE is already evaluated by someone else. I am obviously no expert on the GHC internals, but that is what I understood by reading the papers about the runtime system. So, in GHC I'd say it would make sense to stay in the original thread and throw the exception as Simon Marlow said. Just my 2 eurocents. Cheers, Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: behaviour change in getDirectoryContents in GHC 7.2?
Hi, On 01.11.2011, at 19:43, Max Bolingbroke wrote: As I pointed out earlier in the thread you can recover the old behaviour if you really want it by manually reencoding the strings, so I would dispute the claim that it is impossible to fix within the given API. As far as I know, not all encodings are reversable. I.e. there are byte sequences which are invalid utf-8. Therefore, decoding and re-encoding might not return the exact same byte sequence. Cheers, Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi,
I've continued my search for a proper workaround. Again, I did find some
unexpected results. See below.
On 09.10.2011, at 17:56, wagne...@seas.upenn.edu wrote:
Quoting Jean-Marie Gaillourdet j...@gaillourdet.net:
That sounds plausible. Do you see any workaround? Perhaps repeatedly
evaluating typeOf?
If there's a concurrency bug, surely the workaround is to protect calls to
the non-thread-safe function with a lock.
typeOfWorkaround lock v = do
() - takeMVar lock
x - evaluate (typeOf v)
putMVar lock ()
return x
~d
This is my previous program with your workaround, it is also attached as
TypeRepEqLock.hs
import Control.Concurrent
import Control.Exception
import Control.Monad
import Data.Typeable
import System.IO.Unsafe
main :: IO ()
main =
do { fin1 - newEmptyMVar
; fin2 - newEmptyMVar
; forkIO $ typeOf' () = putMVar fin1
; forkIO $ typeOf' () = putMVar fin2
; t1 - takeMVar fin1
; t2 - takeMVar fin2
; if (t1 /= t2)
then putStrLn $ typeOf ++ show t1 ++ /= typeOf ++ show t2
else putStrLn Ok
}
{-# NOINLINE lock #-}
lock :: MVar ()
lock = unsafePerformIO $ newMVar ()
-- Ugly workaround to http://hackage.haskell.org/trac/ghc/ticket/5540
typeOf' :: Typeable a = a - IO TypeRep
typeOf' x =
do { () - takeMVar lock
; t - evaluate $ typeOf x
; putMVar lock ()
; return t
}
Compile and execute:
$ ghc-7.0.3 -threaded -rtsopts TypeRepEqLock.hs
snip
$ while true ; do ./TypeRepEqLock +RTS -N ; done
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
TypeRepEqLock: thread blocked indefinitely in an MVar operation
Ok
Ok
Ok
^C^C
I'm sorry but I don't see how this program could ever deadlock, unless there is
some more locking in typeOf and (==) on TypeReps.
On the other side, my admittedly ugly workaround works fine for hours and hours.
import Control.Concurrent
import Control.Exception
import Control.Monad
import Data.Typeable
main :: IO ()
main =
do { fin1 - newEmptyMVar
; fin2 - newEmptyMVar
; forkIO $ return (typeOf' ()) = evaluate = putMVar fin1
; forkIO $ return (typeOf' ()) = evaluate = putMVar fin2
; t1 - takeMVar fin1
; t2 - takeMVar fin2
; if (t1 /= t2)
then putStrLn $ typeOf ++ show t1 ++ /= typeOf ++ show t2
else putStrLn Ok
}
typeOf' val
| t1 == t2 = t1
| otherwise = typeOf' val
where
t1 = typeOf'' val
t2 = typeOf''' val
{-# NOINLINE typeOf' #-}
typeOf'' x = typeOf x
{-# NOINLINE typeOf'' #-}
typeOf''' x = typeOf x
{-# NOINLINE typeOf''' #-}
$ ghc-7.0.3 -threaded -rtsopts TypeRepEq.hs
snip
$ while true ; do ./TypeRepEq +RTS -N ; done
Ok
Ok
Ok
Ok
Ok
Ok
…
Any hints how to avoid the thread blocked indefinitely in an MVar operation
exception?
Cheers,
Jean
TypeRepEqLock.hs
Description: Binary data
TypeRepEq.hs
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi Simon, On 12.10.2011, at 10:34, Simon Peyton-Jones wrote: Did you try 7.2? As I mentioned, the issue should have gone away entirely because there is no shared cache any more Yes, I did test it with GHC 7.2. And yes, with GHC 7.2 typeOf is fine. I continued to look into that issue because I am interested in a practically working solution running with GHC 6.12 and 7.0. I am sorry if I didn't make that clear enough. Cheers, Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi Bertram,
On 12.10.2011, at 13:24, Bertram Felgenhauer wrote:
This has nothing to do with Data.Typeable though - it appears to be some
interaction between unsaferPerformIO and MVars that I do not understand.
The following program occasionally terminates with thread blocked
indefinitely in an MVar operation, too (tested on ghc 7.0.3 and 7.2.1):
import Control.Concurrent
import Control.Exception
import Control.Monad
import System.IO.Unsafe
main :: IO ()
main = do
-- evaluate lock -- adding this line fixes the problem
fin1 - newEmptyMVar
fin2 - newEmptyMVar
forkIO $ ping = putMVar fin1
forkIO $ ping = putMVar fin2
takeMVar fin1
takeMVar fin2
{-# NOINLINE lock #-}
lock :: MVar ()
lock = unsafePerformIO $ newMVar ()
ping = do
() - takeMVar lock
putMVar lock ()
Since I don't yet understand why this blocks, I cannot say whether it
should work or not.
I've seen blocks with GHC 6.12.1, but I never got one with 7.0.3 and 7.2.1.
Probably, bad luck on my side. ;-)
Cheers,
Jean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Is this a concurrency bug in base?
Hi,
I am working on a library I'd like to release to hackage very soon, but I've
found a problem with supporting GHC 6.12 and GHC 7.0.
Consider the following program:
import Control.Concurrent
import Data.Typeable
main :: IO ()
main =
do { fin1 - newEmptyMVar
; fin2 - newEmptyMVar
; forkIO $ typeRepKey (typeOf ()) = print putMVar fin1 ()
; forkIO $ typeRepKey (typeOf ()) = print putMVar fin2 ()
; () - takeMVar fin1
; () - takeMVar fin2
; putStrLn ---
; return ()
}
When compiled with GHC 7.0.x or GHC 6.12.x, it should print two identical
numbers. Sometimes it does not.
To reproduce this compile and execute as follows:
$ ghc-7.0.3 -rtsopts -threaded TypeRepKey.hs -o TypeRepKey
$ while true ; do ./TypeRepKey +RTS -N ; done
0
0
---
0
0
---
0
0
---
0
1
---
0
0
---
…
Ideally you should get an infinite number of zeros but once in a while you have
a single(!) one in between. The two numbers of one program run should be
identical, but their values may be arbitrary. But it should not be possible to
have single outliers.
This only happens when executed with more than one thread. I've also a somewhat
larger program which seems to indicate that fromDynamic fails occasionally. I
can post it as well if it helps. This seems to be a Heisenbug as it is
extremely fragile, when adding a | grep 1 to the while loop it seems to
disappears. At least on my computers.
All this was done on several Macs running the latest OS X Lion with ghc 7.0.3
from the binary distribution on the GHC download page.
Actually, I am trying to find a method to use a type as key in a map which
works before GHC 7.2. I'd be glad to get any ideas on how to achieve that,
given that typeRepKey seems to buggy.
I'd be happy to get any comments on this matter.
Regards,
Jean
TypeRepKey.hs
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi Daniel, On 09.10.2011, at 14:45, Daniel Fischer wrote: On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote: This seems to be a Heisenbug as it is extremely fragile, when adding a | grep 1 to the while loop it seems to disappears. At least on my computers. Still produces 1s here with a grep. Well, it may have been bad luck on my site. All this was done on several Macs running the latest OS X Lion with ghc 7.0.3 from the binary distribution on the GHC download page. linux x86_64, ghc-7.0.4, 7.0.2 and 6.12.3. Indeed 6.12.3 goes so far to sometimes produce 0 0 --- 10 --- 0 0 --- 01 --- i.e. it switches threads during print. Thanks, for reproducing it. I failed to see it on Linux so far. So I guess a bug report is in order? Or are bug reports to old versions not welcome? Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi,
the Eq instance of TypeRep shows the same non-deterministic behavior:
import Control.Concurrent
import Control.Exception
import Control.Monad
import Data.Typeable
main :: IO ()
main =
do { fin1 - newEmptyMVar
; fin2 - newEmptyMVar
; forkIO $ return (typeOf ()) = evaluate = putMVar fin1
; forkIO $ return (typeOf ()) = evaluate = putMVar fin2
; t1 - takeMVar fin1
; t2 - takeMVar fin2
; when (t1 /= t2) $
putStrLn $ typeOf ++ show t1 ++ /= typeOf ++ show t2
}
$ ghc-7.0.3 -threaded -rtsopts TypeRepEq.hs
snip
$ while true ; do ./TypeRepEq +RTS -N ; done
typeOf () /= typeOf ()
typeOf () /= typeOf ()
^C^C
$
On 09.10.2011, at 16:04, David Brown wrote:
The program below will occasionally print 1 /= 0 or 0 /= 1 on
x86_64 linux with the Debian testing 7.0.4 ghc.
$ ghc bug -rtsopts -threaded
$ while true; do ./bug +RTS -N; done
module Main where
import Control.Monad
import Control.Concurrent
import Data.Typeable
main :: IO ()
main = do
fin1 - newEmptyMVar
fin2 - newEmptyMVar
forkIO $ child fin1
forkIO $ child fin2
a - takeMVar fin1
b - takeMVar fin2
when (a /= b) $
putStrLn $ show a ++ /= ++ show b
child :: MVar Int - IO ()
child var = do
key - typeRepKey (typeOf ())
putMVar var key
Thanks again for reproducing it.
Jean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi Daniel, On 09.10.2011, at 16:24, Daniel Fischer wrote: On Sunday 09 October 2011, 15:30:20, Jean-Marie Gaillourdet wrote: Hi Daniel, On 09.10.2011, at 14:45, Daniel Fischer wrote: On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote: This seems to be a Heisenbug as it is extremely fragile, when adding a | grep 1 to the while loop it seems to disappears. At least on my computers. Still produces 1s here with a grep. Well, it may have been bad luck on my site. Or maybe Macs behave differently. Thanks, for reproducing it. I failed to see it on Linux so far. So I guess a bug report is in order? I'd think so. Although due to the changes in 7.2 there's nothing to fix here anymore, it might point to something still to be fixed. Or are bug reports to old versions not welcome? Within reason. Reporting bugs against 5.* would be rather pointless now, but = 6.10 should be okay. If the behaviour has been fixed as a by-product of some other change, at least a test could be made to prevent regression. If, like here, the directly concerned code has been changed, probably nothing is to be done, but the bug may have been caused by something else which still needs to be fixed, so better report one bug too many. I've been chasing the source of the non-deterministic of my library for quite some time now. And at several points in time I had the impression that modifyMVar would not always be atomic. (Of course under the assumption that no other code touches the MVar). But in that case as well as in the case here it is only reproducible by looping the execution of the binary. Moving the loop into the Haskell program will show the bug in the first iteration or never. I will report a bug. Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
On 09.10.2011, at 16:40, Jean-Marie Gaillourdet wrote: I will report a bug. http://hackage.haskell.org/trac/ghc/attachment/ticket/5540/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi,
On 09.10.2011, at 17:27, Daniel Fischer wrote:
Jean-Marie Gaillourdet:
the Eq instance of TypeRep shows the same non-deterministic behavior:
Of course, equality on TypeReps is implemented by comparison of the Keys.
On Sunday 09 October 2011, 16:40:13, Jean-Marie Gaillourdet wrote:
Hi Daniel,
I've been chasing the source of the non-deterministic of my library for
quite some time now. And at several points in time I had the impression
that modifyMVar would not always be atomic.
It isn't:
MVars offer more flexibility than IORefs, but less flexibility than STM.
They are appropriate for building synchronization primitives and performing
simple interthread communication; however they are very simple and
susceptible to race conditions, deadlocks or uncaught exceptions. Do not
use them if you need perform larger atomic operations such as reading from
multiple variables: use STM instead.
In particular, the bigger functions in this module (readMVar, swapMVar,
withMVar, modifyMVar_ and modifyMVar) are simply the composition of a
takeMVar followed by a putMVar with exception safety. These only have
atomicity guarantees if all other threads perform a takeMVar before a
putMVar as well; otherwise, they may block.
But I don't think that's the problem here.
(Of course under the
assumption that no other code touches the MVar).
This sentence referred to what you explained above. Although, my reference was
quite cryptic.
But in that case as
well as in the case here it is only reproducible by looping the
execution of the binary. Moving the loop into the Haskell program will
show the bug in the first iteration or never.
That's what I expect.
I think what happens is:
-- from Data.Typeable
cache = unsafePerformIO $ ...
mkTyConKey :: String - Key
mkTyConKey str
= unsafePerformIO $ do
let Cache {next_key = kloc, tc_tbl = tbl} = cache
mb_k - HT.lookup tbl str
case mb_k of
Just k - return k
Nothing - do { k - newKey kloc ;
HT.insert tbl str k ;
return k }
occasionally, the second thread gets to perform the lookup before the first
has updated the cache, so both threads create a new entry and update the
cache.
If you loop in the Haskell programme, after the first round each thread
definitely finds an entry for (), so the cache isn't updated anymore.
That sounds plausible. Do you see any workaround? Perhaps repeatedly evaluating
typeOf?
Jean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
Hi,
On 09.10.2011, at 17:37, Jean-Marie Gaillourdet wrote:
Hi,
On 09.10.2011, at 17:27, Daniel Fischer wrote:
That's what I expect.
I think what happens is:
-- from Data.Typeable
cache = unsafePerformIO $ ...
mkTyConKey :: String - Key
mkTyConKey str
= unsafePerformIO $ do
let Cache {next_key = kloc, tc_tbl = tbl} = cache
mb_k - HT.lookup tbl str
case mb_k of
Just k - return k
Nothing - do { k - newKey kloc ;
HT.insert tbl str k ;
return k }
occasionally, the second thread gets to perform the lookup before the first
has updated the cache, so both threads create a new entry and update the
cache.
If you loop in the Haskell programme, after the first round each thread
definitely finds an entry for (), so the cache isn't updated anymore.
That sounds plausible. Do you see any workaround? Perhaps repeatedly
evaluating typeOf?
typeOf' seems to be a working workaround:
typeOf' val
| t1 == t2 = t1
| otherwise = typeOf' val
where
t1 = typeOf'' val
t2 = typeOf''' val
{-# NOINLINE typeOf' #-}
typeOf'' x = typeOf x
{-# NOINLINE typeOf'' #-}
typeOf''' x = typeOf x
{-# NOINLINE typeOf''' #-}
Jean
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
On 09.10.2011, at 17:56, wagne...@seas.upenn.edu wrote: Quoting Jean-Marie Gaillourdet j...@gaillourdet.net: That sounds plausible. Do you see any workaround? Perhaps repeatedly evaluating typeOf? If there's a concurrency bug, surely the workaround is to protect calls to the non-thread-safe function with a lock. typeOfWorkaround lock v = do () - takeMVar lock x - evaluate (typeOf v) putMVar lock () return x Yes, but this workaround is in the IO monad while mine is not. Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is this a concurrency bug in base?
On 09.10.2011, at 18:13, Daniel Fischer wrote:
On Sunday 09 October 2011, 17:51:06, Jean-Marie Gaillourdet wrote:
That sounds plausible. Do you see any workaround? Perhaps repeatedly
evaluating typeOf?
typeOf' seems to be a working workaround:
typeOf' val
| t1 == t2 = t1
| otherwise = typeOf' val
where
t1 = typeOf'' val
t2 = typeOf''' val
{-# NOINLINE typeOf' #-}
typeOf'' x = typeOf x
{-# NOINLINE typeOf'' #-}
typeOf''' x = typeOf x
{-# NOINLINE typeOf''' #-}
That'll make it very improbable to get bad results, but not impossible.
Thread1: typeOf' (); typeOf'' (), lookup, not there
Thread2: typeOf' (); typeOf'' (), lookup, not there
Thread1: create and insert; typeOf''' (), entry present, use ~ Key 0
Thread2: create and insert, overwites entry with Key 0,
new entry has Key 1; typeOf''' (), entry present, use ~ Key 1
It will probably take a long time until it bites, but when it does, it will
hurt.
A proper fix would need a lock to ensure only one thread at a time can
access the cache.
Ok, you're right. I tried to avoid the IO monad, but there seems to be no way
around it.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: building GHC on a cluster
Hi,
On 23.08.11 17:10, Karel Gardas wrote:
Hello,
recent GHC build times on newer MacBook Pros? thread makes me
wondering if someone already attempted to build GHC on a cluster of
machines using for example PVM GNU make[1] for this or any other tool (
or even custom generated bin/ghc-stageX scripts using rsh?) which is
suitable for the task. I'm asking since build of GHC HEAD on my
ARM/Linux (OMAP4 1GHz) using both cores takes around 7 hours and yet
buying another 3 machines might be well in the finance envelope of hobby
project and speed the development which usually happens only during
weekend's evenings...
Thanks!
Karel
[1]: http://pvmgmake.sourceforge.net/
At least the C compilations should be easily distributable with distcc
[1]. I've had great success using it with pure C projects in the past. I
don't know if compiling the runtime system takes long enough to make
distribution wortwhile.
Regards,
Jean
[1]: http://code.google.com/p/distcc/
--
Jean-Marie Gaillourdet
blog: gaillourdet.net
{email, xmpp, jabber, ichat, gimix, gtalk}:j...@gaillourdet.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
Hi Simon, Simon Peyton-Jones simo...@microsoft.com writes: | known problem with darcs with no obvious solution. For me, switching | GHC to git would certainly be a win. I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite how to understand git doc, do point me at it. I've felt the same for quite some time. Therefore I used to prefer mercurial, because of its way more consistent user interface. But my view has changed after I've seen this [1] introduction of magit [2] an emacs git user interface. Now, I feel at least capable of working with git in emacs. [1] http://vimeo.com/2871241 [2] http://philjackson.github.com/magit/ Cheers, Jean-Marie ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Documentation of System.Process
Hi Simon, thanks for the clarification. Regards, Jean Simon Marlow marlo...@gmail.com writes: On 26/11/2010 10:00, Jean-Marie Gaillourdet wrote: Hi all, I've been searching information regarding file handles to pipes created by System.Process.createProcess. The documentation does not state whether they are in binary mode, i.e. whether they have line ending conversion or an encoding enabled. That kind of information is available for runInteractiveCommand in the same module. runInteractiveCommand opens all pipes in binary mode. I've concluded from the source of that module that the same is probably true for createProcess. I've two questions now: 1. Is it correct that createProcess returns file handles in binary mode when creating pipes? No, in fact the Handles use localeEncoding and nativeNewlineMode by default. You can use hSetBinaryMode if you want no encoding or newline translation. 2. Could you add that information to the haddock docs? Yes. Is their some other place where I could have found this? The source :-) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Documentation of System.Process
Hi all, I've been searching information regarding file handles to pipes created by System.Process.createProcess. The documentation does not state whether they are in binary mode, i.e. whether they have line ending conversion or an encoding enabled. That kind of information is available for runInteractiveCommand in the same module. runInteractiveCommand opens all pipes in binary mode. I've concluded from the source of that module that the same is probably true for createProcess. I've two questions now: 1. Is it correct that createProcess returns file handles in binary mode when creating pipes? 2. Could you add that information to the haddock docs? Is their some other place where I could have found this? Thanks for your great work! Regards, Jean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using associated data types to create unpacked data structures
Hi,
On 12.08.2010, at 12:25, Simon Marlow wrote:
On 12/08/2010 11:13, Johan Tibell wrote:
There needs to be some amount of code generation, but much of the
implementation can still be shared. I previously tried to defined the
type class as
{-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-}
module Ex2 where
import Prelude hiding (lookup)
data MapView k v = TipView
| BinView {-# UNPACK #-} !Size !k !v !(Map k v)
!(Map k v)
class Unbox k v where
data Map k v :: *
tip :: Map k v
bin :: Size - k - v - Map k v - Map k v - Map k v
view :: Map k v - MapView k v
type Size = Int
lookup :: (Ord k, Unbox k v) = k - Map k v - Maybe v
lookup k m = case view m of
TipView - Nothing
BinView _ kx x l r - case compare k kx of
LT - lookup k l
GT - lookup k r
EQ - Just x
{-# INLINE lookup #-}
Calling lookup from a different module at a know type gives exactly the
Core you'd like to see (unpacked types, no MapView constructors).
I'm not sure I want lookup (and other operations) to be inlined at every call
site though.
Wouldn't it be better to enable specialize pragmas from outside the defining
module. Then a user of the Ex2 could declare his need for an optimized version
of lookup for his particular type. Of course, that would require the inclusion
of lookup into the .hi file.
-- Jean___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Deadlock with Repa
Hi, I've been trying to use repa and stumbled into rather strange behavior of my program. Sometimes, there seems to be a deadlock at other times it seems there is a livelock. Now, I've managed to prepare a version which consistently generates the following output: $ ./MDim MDim: thread blocked indefinitely in an MVar operation $ But I don't use any MVar directly. And the only used library which is not part of ghc are repa and repa-algorithms. To state it clearly I don't use any MVars, par, pseq, forkIO nor any other parallelism or cuncurrency functionality. The only thing my program uses is repa which is supposed to use some kind of parallelism as far as the documentation says. So I am wondering whether this is a problem with my code or with repa or with ghc. The same behaviour occurs with ghc-6.12.1 and ghc-6.13.20100726. This is on MacOSX 10.6.4. In order to reproduce take the attached file and compile it with: $ ghc --make -package dph-prim-par MDim.hs -main-is MDim -fforce-recomp [1 of 1] Compiling MDim ( MDim.hs, MDim.o ) Linking MDim ... $ ./MDim MDim: thread blocked indefinitely in an MVar operation $ I haven't been able to make the program smaller without removing the blockage. But, essentially it's just pure number crunching you can ignore. I'd be really happy if anyone could give me a hint how to debug this, or whether I am able to do anything about it, at all. Best regards, Jean-Marie MDim.hs Description: Binary data -- Dipl.-Inf. Jean-Marie Gaillourdet Software Technology Group University of Kaiserslautern, Department of Computer Science Gebäude 32, Raum 406 Gottlieb-Daimler-Str. D-67653 Kaiserslautern Tel: 06 31 - 205 - 32 72 Fax: 06 31 - 205 - 34 20 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Feedback request: priority queues in containers
Hi, I think this is my first post to this list although I've been reading it for a long time. So, please, be patient with me and my post. On 03/16/2010 02:29 PM, Louis Wasserman wrote: * We offer Functor, Foldable, and Traversable instances that do not respect key ordering. All are linear time, but Functor and Traversable in particular assume the function is monotonic. The Foldable instance is a good way to access the elements of the priority queue in an unordered fashion. (We also export mapMonotonic and traverseMonotonic, and encourage the use of those functions instead of the Functor or Traversable instances.) So, it is possible to break the invariants of your priority queue by using fmap with a non-monotonic function, right? I see that it might be usefull to have such instances, sometimes. As it is not possible to hide instances, once they are definded, I'd propose to not offer those instances by default. Instead you could provide implementations of all the instance functions necessary to define this instances yourself. Or one could have a newtype wrapper around the priority queue for which instances of Function, Foldable, and Traversable are defined. This would allow to activate the nice instances on demand but to stay safe by default. Best regards, Jean-Marie ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
