Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr
On Tue, Nov 9, 2010 at 5:37 PM, Mitar wrote: > Why is ThreadKilled not displayed by RTS when send to thread (and > unhandled), but any other exception is? A ThreadKilled exception is not printed to stderr because it's not really an error and should not be reported as such. It is also clear how to handle a ThreadKilled: just abort the thread and silently terminate. All other exceptions raised in or thrown to the thread which are not handled by the thread itself should be considered errors and reported as such. To see what happens under the hood look at the implementation of forkIO by clicking on the 'Source' link next to the type signature: http://hackage.haskell.org/packages/archive/base/4.2.0.2/doc/html/Control-Concurrent.html#v%3AforkIO The 'action_plus' that is forked catches all exceptions and handles them with childHandler: ... where action_plus = catchException action childHandler childHandler in turn calls real_handler to handle the exception but registers an exception handler so that exceptions raised by the real_handler are handled again recursively: childHandler :: SomeException -> IO () childHandler err = catchException (real_handler err) childHandler Now real_handler handles the exceptions BlockedIndefinitelyOnMVar, BlockedIndefinitelyOnSTM and ThreadKilled by just returning. All other exceptions are reported: real_handler :: SomeException -> IO () real_handler se@(SomeException ex) = -- ignore thread GC and killThread exceptions: case cast ex of Just BlockedIndefinitelyOnMVar-> return () _ -> case cast ex of Just BlockedIndefinitelyOnSTM-> return () _ -> case cast ex of Just ThreadKilled -> return () _ -> case cast ex of -- report all others: Just StackOverflow -> reportStackOverflow _ -> reportError se > For example, I am using custom exceptions to signal different kinds of > thread killing. Based on those my threads cleanup in different ways. > But after they cleanup they keep "running". Not really running as > their computations were interrupted. But simply hanging there. And if > then new custom exception arrives it is not handled anymore (as it is > after my normal exception handlers already cleaned everything) and it > is printed to stderr. What do you mean by "hanging there". Are they blocked on an MVar? > Now I added "`finally` throwIO ThreadKilled" at the end of my cleanup > computations to really kill the thread. So that possible later > exceptions are not delivered anymore. That shouldn't be necessary. If the cleanup action is the last action of the thread then the thread will terminate when it has performed the cleanup. > Why it is not so that after all computations in a thread finish, > thread is not killed/disposed of? It actually should. I think any other behavior is a bug. It would help if you could show us your code (or parts of it). Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wadler space leak
Let me clarify a bit exactly how Gustavsson and Sands (I'll refer to them as GS) handled the issue of the Wadler space leak. It's true that they adopted an approach similar to Sparud in that they extended their core calculus with a new language construct which could solve the problem. This is contrast to Wadler who changed the garbage collector instead, something that GS said would lead to bad behavior in their calculus. BUT, GS did not adopt exactly the construct that Sparud suggested. Sparud's suggestion was to add an updatePat primitive to the language. This was inspired by how the G-machine work, it had update instructions which where typically executed after a value was computed. It's a rather bad fit for the STG-machine which pushes update markers on the stack whenever it starts to evaluate a thunk. Updates are performed whenever there is an update marker on the stack when it has computed something to WHNF. The language construct that GS chose was to have pattern bindings as primitive in the language. So the code snippet below (taken from Jörgen's thesis) would be a valid core program. It would not be desugared into case expressions. ~~~ let (ps,qs) = split ys in (y:ps,qs) ~~~ The semantics of pattern bindings involves a new kind of update marker which, in the example above, will update both ps and qs, whenever the 'split ys' is computed to WHNF. This neatly solves the space leak problem. And it is a much closer fit to the STG-machine in that uses update markers on the stack to coordinate the graph reduction. I think the solution GS chose should work much better for GHC than Sparud's suggestion. But it would no doubt be an invasive change to GHC as Core would have to be changed to support pattern bindings. Cheers, Josef On Tue, Nov 9, 2010 at 8:58 AM, Duncan Coutts wrote: > On 8 November 2010 13:28, Simon Marlow wrote: > > > > There's another approach in Jan Sparud's paper here: > > > > http://portal.acm.org/citation.cfm?id=165196 > > > > although it's not clear that this interacts very well with inlining > either, > > and it has a suspicious-looking side-effecting operation. It also looks > > like it creates a circular reference between the thunk and the selectors, > > which might hinder optimisations, and would probably also make things > slower > > (by adding extra free variables to the thunk). > > This proposal is mentioned favourably by Jörgen Gustavsson David Sands > in [1] (see section 6, case study 6). They mention that there is a > formalisation in Gustavsson's thesis [2]. That may say something about > inlining, since that's just the kind of transformation they'd want to > show is a space improvement. > > [1]: Possibilities and Limitations of Call-by-Need Space Improvement (2001) > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.4097 > > [2]: Space-Safe Transformations and Usage Analysis for Call-by-Need > Languages (2001) > (which I cannot immediately find online) > > Duncan > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: os x 64-bit?
On 11/09/2010 02:36 AM, John Lato wrote: > I was wondering if there is a status report anywhere of progress towards > making ghc compile 64-bit on Snow Leopard. There are a few trac tickets > that seem related: I think http://hackage.haskell.org/trac/ghc/ticket/3472 is related if you haven't seen it. I'm not working on this, though I am interested in helping enable cross-compilation of GHC in general. I have been working on one facet though: hsc2hs. hsc2hs is one of barriers to cross-compilation because it requires compiling and running a .c file on the target machine (because it needs target-specific information like the layout of structures; GHC's mkDerivedConstants also has the same problem). I have a proof-of-concept patch which can do hsc2hs codegeneration without running anything. This uses the same approach that autoconf uses for cross-compilation. I'll try to post it within the next few days -- if anybody finds this approach interesting please let me know. Thanks, -Brian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Printing of asynchronous exceptions to stderr
Hi! I have been spend some time to debug this in my program. ;-) Why is ThreadKilled not displayed by RTS when send to thread (and unhandled), but any other exception is? For example, I am using custom exceptions to signal different kinds of thread killing. Based on those my threads cleanup in different ways. But after they cleanup they keep "running". Not really running as their computations were interrupted. But simply hanging there. And if then new custom exception arrives it is not handled anymore (as it is after my normal exception handlers already cleaned everything) and it is printed to stderr. Now I added "`finally` throwIO ThreadKilled" at the end of my cleanup computations to really kill the thread. So that possible later exceptions are not delivered anymore. Why it is not so that after all computations in a thread finish, thread is not killed/disposed of? Because it can be reused by some other computation? But then my exceptions could be delivered to wrong (new) thread while they were meant for old one? Mitar ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
> instance (EmbedAsChild m c, m1 ~ m) => EmbedAsChild m (XMLGenT m1 c)
That looked to me like a long-winded way of saying:
> instance (EmbedAsChild m c) => EmbedAsChild m (XMLGenT m c)
Unless I'm missing something?
These two instances are not equivalent:
- the first matches even if m and m1 differ, causing a type-error.
- the second matches only if m~m1
Claus
{-# LANGUAGE OverlappingInstances #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
class C a bwhere c :: a -> b -> Bool
instance C a a where c _ _ = True
instance C a b where c _ _ = False
class D a b where d :: a -> b -> Bool
instance a~b=>D a b where d _ _ = True
-- instance D a b where d _ _ = False -- would be a duplicate instance
{-
*Main> c () ()
True
*Main> c () True
False
*Main> d () ()
True
*Main> d () True
:1:0:
Couldn't match expected type `Bool' against inferred type `()'
When generalising the type(s) for `it'
-}
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
I'm not sure whether to reply to the list(s) or the ticket; maybe if you
think my comments are valid they can be copied to the ticket. From
looking, it seems to me that you do have overlapping instances, and I
wonder if it's actually a 6.12 bug for accepting the code, not a 7 bug
for rejecting it. I took your XMLGenerator.lhs file from the ticket and
loaded it in GHC 6.12; it loaded fine. Then I looked through and
squinted at this instance:
> instance (EmbedAsChild m c, m1 ~ m) => EmbedAsChild m (XMLGenT m1 c)
That looked to me like a long-winded way of saying:
> instance (EmbedAsChild m c) => EmbedAsChild m (XMLGenT m c)
Unless I'm missing something? So I made that change, then loaded it
again. Suddenly I have overlapping instances in 6.12:
XMLGenerator.lhs:64:16:
Overlapping instances for EmbedAsChild
(IdentityT IO) (XMLGenT m (XML m))
arising from a use of `asChild' at XMLGenerator.lhs:64:16-22
Matching instances:
instance [overlap ok] (XML m ~ x, XMLGen m) => EmbedAsChild m x
-- Defined at XMLGenerator.lhs:37:11-52
instance [overlap ok] (EmbedAsChild m c) =>
EmbedAsChild m (XMLGenT m c)
-- Defined at XMLGenerator.lhs:31:11-60
It seems to me that the two instances can overlap; consider if I define
an instance for XMLGen:
> data WhateverM
> instance XMLGen WhateverM where
> type XML WhateverM = XMLGenT WhateverM ()
At that point your instances would overlap if I want an instance for
EmbedAsChild WhateverM (XMLGenT WhateverM ()). My understanding of the
way type-classes are checked is that since that instance could exist
somewhere in a different module, we must reject the two instances for
EmbedAsChild. (Or rather: ignoring the head of the instance
declarations, the instances can overlap.) But I may be wrong!
So my guess is you've always had overlapping instances (assuming this
code is representative of your original), and my hypothesis is that the
use of "~" in one of the instances was somehow stopping GHC 6.12 from
spotting this.
Thoughts (and corrections!) welcome.
Thanks,
Neil.
On 08/11/10 23:30, Jeremy Shaw wrote:
Hello,
I have narrowed this down further to a single file. And created a trac
bug for it:
http://hackage.haskell.org/trac/ghc/ticket/4485
This is (the only thing?) holding up HSP and happstack moving to GHC 7.
- jeremy
On Tue, Nov 2, 2010 at 5:36 PM, Jeremy Shaw wrote:
Hello,
I have a module, XMLGenerator, which has some overlapping instances.
I have a second module, Test, which imports that module and also adds
some more overlapping instances.
Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top.
Under some old version of 6.13 (and probably 6.12), if I put both
modules in the same directory and try to load Test.hs, it gets the
error:
Test.hs:16:15:
Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
arising from a use of `asChild' at Test.hs:16:15-21
Matching instances:
instance (m1 ~ m, EmbedAsChild m c) =>
EmbedAsChild m (XMLGenT m1 c)
-- Defined at XMLGenerator.hs:16:10-68
instance (XML m ~ x, XMLGen m) => EmbedAsChild m x
-- Defined at XMLGenerator.hs:19:10-51
In the first argument of `($)', namely `asChild'
In the expression: asChild $ (genElement "foo")
In the definition of `asChild':
asChild b = asChild $ (genElement "foo")
If I put the XMLGenerator module in a separate package, dummy-hsx, and
the Test modules links against it, I still get the error.
*but* if I add:
Extensions: OverlappingInstances
to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for
starters, I do not understand why that happens.
Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I
always get the error:
Test.hs:16:15:
Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
arising from a use of `asChild'
Matching instances:
instance [overlap ok] (m1 ~ m, EmbedAsChild m c) =>
EmbedAsChild m (XMLGenT m1 c)
-- Defined in XMLGenerator
(The choice depends on the instantiation of `m'
To pick the first instance above, use -XIncoherentInstances
when compiling the other instance declarations)
Adding the IncoherentInstances flag does make it compile -- but I have
never enabled that flag and not regretted it.
What changed between GHC 6.12 and GHC 7.0? Is there a some solution
besides using IncoherentInstances in every module that imports
XMLGenerator?
I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal.
thanks!
- jeremy
___
Haskell-Cafe mailing list
haskell-c...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/m
Re: Wadler space leak
On 9 November 2010 07:58, Duncan Coutts wrote: > This proposal is mentioned favourably by Jörgen Gustavsson David Sands > in [1] (see section 6, case study 6). They mention that there is a > formalisation in Gustavsson's thesis [2]. That may say something about > inlining, since that's just the kind of transformation they'd want to > show is a space improvement. During development of my supercompiler, I noticed that a feature like this one (explicit thunk update in the intermidate language) would enable more deforestation in rare circumstances. First step is to build an alternative operational semantics for Core which includes explicit thunk update. First, we add to the term syntax something of the form "update x v e" where: * x is a variable * v is either 1) A syntactic value 2) Or a variable pointing to something that is certainly evaluated, by which we mean that the corresponding binding is either: a) The "wildcard" binder of a case expression (or equivalently the variable bound by its default alternative) b) A let with a value RHS * e is a term We give this new syntax this operational semantics in the standard Sestoft abstract machine for call by need: < H | update x v e | K > --> < H, x |-> v | e | K > We also need to change the variable rule in the standard semantics from: < H, x |-> e | x | K > --> < H | e | update x, K > To: < H, x |-> e | x | K > --> < H | e | K > So now plain "let" only expresses code sharing, not work sharing. You can then desugar Haskell lets as follows: DESUGAR[let x = e1 in e2] :: Haskell = let x = (case DESUGAR[e1] of FRESH -> update x FRESH FRESH) in DESUGAR[e2] :: Core i.e. Haskell lets are work shared. The additional power we get in this scheme is that the v and e in "update x v e" needn't have the same semantics. To see why this is useful, consider this Haskell program: """ let x = case f x of A y -> A (g y) B z -> B (h z) C -> C in case x of A y -> y B z -> z C -> 10 """ In desugared form (I've omitted the update frames for the thunk in the argument of A/B since its irrelevant for this example), we get: """ let x = case (case f x of A y -> A (g y) B z -> B (h z) C -> C) of x_fresh -> update x x_fresh x_fresh in case x of A y -> y B z -> z C -> 10 """ Now we could transform our original program as follows by doing case-of-case ***through the update frame for x***. First, push the update frame into the case branches: """ let x = case f x of A y -> case A (g y) of x_fresh -> update x x_fresh x_fresh B z -> case B (h z) of x_fresh -> update x x_fresh x_fresh C -> case C of x_fresh -> update x x_fresh x_fresh in case x of A y -> y B z -> z C -> 10 """ Now move the case consuming of "x" into the case branches, then into the inner case expressions, then into the argument of the "update" construct. We end up with: """ let x = error "Black hole: x" in case f x of A y -> case A (g y) of x_fresh -> update x x_fresh (case x_fresh of A y -> y B z -> z C -> 10) B z -> case B (h z) of x_fresh -> update x x_fresh (case x_fresh of A y -> y B z -> z C -> 10) C -> case C of x_fresh -> update x x_fresh (case x_fresh of A y -> y B z -> z C -> 10) """ Note that I've had to keep around a binding for "x" so that the "update x" has something to update, and in case "f" is strict in its argument. Now we can do some trivial simplifications to get this code: """ let x = error "Black hole: x" in case f x of A y -> let y' = g y x_fresh = A y' in update x x_fresh y' B z -> let z' = h z x_fresh = B z' in update x x_fresh z' C -> let x_fresh = C in update x x_fresh 10 """ Now we can spot that the "update x" in the C branch writes memory that cannot be read, since "x" cannot escape through the literal 10. So we can transform as follows: """ let x = error "Black hole: x" in case f x of A y -> let y' = g y x_fresh = A y' in update x x_fresh y' B z -> let z' = h z x_fresh = B z' in update x x_fresh z' C -> 10 """ None of the other transformations increase allocation, and this last one reduces allocation by 1 in the case that f x == C -- so we have deforested the C. What's more, we avoid any case scrutinisation on the A and B constructors built in the branches of the original case, though we still have to allocate them since f might have closed over x. AFAIK it is impossible to achieve this in any other way without either risking work duplication
Re: [Haskell-cafe] Re: change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
On 09/11/10 11:53, Neil Brown wrote: XMLGenerator.lhs:64:16: Overlapping instances for EmbedAsChild (IdentityT IO) (XMLGenT m (XML m)) arising from a use of `asChild' at XMLGenerator.lhs:64:16-22 Matching instances: instance [overlap ok] (XML m ~ x, XMLGen m) => EmbedAsChild m x -- Defined at XMLGenerator.lhs:37:11-52 instance [overlap ok] (EmbedAsChild m c) => EmbedAsChild m (XMLGenT m c) -- Defined at XMLGenerator.lhs:31:11-60 I think I should expand slightly more on this bit, especially since I chopped off the useful line "The choice depends on the instantiation of `m'". The problem is that depending on the choice of m in the instance (the "EmbedAsChild (IdentityT IO) (XMLGenT m (XML m))" part), you may or may not match the second overlapping instance. If you choose m=IdentityT IO then it matches the second instance, if you choose anything else then it won't, so GHC can't tell at this point which instance to choose. Which makes them not just overlapping, but also leaves no clear choice (which is why it prompts you to use IncoherentInstances). When you typed the genElement "foo" part explicitly and gave a type to the monad m, that fixed the ambiguity. So I think it's not even that you needed incoherent instances, you have an unresolvable ambiguity if the type of m is left to be inferred. So I still think the question is why the old instance with the "~" worked fine. (Does this help, or am I telling you what you've already worked out for yourself?) Thanks, Neil. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
os x 64-bit?
Hello, I was wondering if there is a status report anywhere of progress towards making ghc compile 64-bit on Snow Leopard. There are a few trac tickets that seem related: 4263: http://hackage.haskell.org/trac/ghc/ticket/4163 2965: (not sure, trac says the database is locked when I try to look at this one) Is Ian working on this, or anyone else? I'd like to help if I can, and I was wondering where would be the best place to start? I probably won't actually contribute much, but this seems as good a way as any for me to start working with ghc. Cheers, John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.1 Release Candidate 2
On 30 October 2010 04:38, Ian Lynagh wrote: > > We are pleased to announce the second release candidate for GHC 7.0.1: > > http://new-www.haskell.org/ghc/dist/7.0.1-rc2/ : > Please test as much as possible; bugs are much cheaper if we find them > before the release! Thanks I did a test build for Fedora: http://koji.fedoraproject.org/koji/taskinfo?taskID=2586133 if people want to try and test it that would be great. Jens ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
