Re: Failure to catch C++ exception in Haskell on OS X

[Bas van Dijk]

On Fri, 4 Jan 2019 at 23:46, Adam Sandberg Eriksson
 wrote:
> A ticket which seems to cover the same problem: 
> https://ghc.haskell.org/trac/ghc/ticket/11829

Wonderful! I can confirm[1] that adding the following to the cabal
file fixes the problem:

  if os(darwin)
ld-options: -Wl,-keep_dwarf_unwind

Shouldn't GHC do this by default when linking on OS X?

Bas

[1] 
https://github.com/basvandijk/darwin-cxx-exception-bug/commit/9b48441606d2fe364c2a21a4ca8ba6b7ff735fe5
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Failure to catch C++ exception in Haskell on OS X

[Bas van Dijk]

On Fri, 4 Jan 2019 at 14:15, Gabor Greif  wrote:
> maybe some DWARF unwind tables are not correctly installed in OS X?

Hi Gabor, thanks, I will look into that.

> Do intra-C++ exception catching work in your example?

Yes, I have a C++ executable foo[1] that links with libfoo that
correctly catches the exception:

  > $(nix-build --no-link -A foo)/bin/test
  ...
  Whoops!

Since it's working in pure C++ I suspect it has something to do with
how GHC calls either the C++ compiler or linker.

Bas

[1] 
https://github.com/basvandijk/darwin-cxx-exception-bug/blob/master/foo/test.cpp
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Failure to catch C++ exception in Haskell on OS X

[Bas van Dijk]

Dear GHC Devs,

I'm debugging an issue in our haskell-opencv library where a C++ exception
that is thrown by the OpenCV C++ library isn't caught by the C++
try...catch block we have inlined in our Haskell code using inline-c-cpp.
This results in the process terminating by SIGABRT.

Note that this only happens on OS X. In Linux the exception is caught
correctly.

I wrote a minimal isolated test case (which doesn't use OpenCV) at:

  https://github.com/basvandijk/darwin-cxx-exception-bug

I wrote some instructions in the README on how to reproduce this and
included some debugging notes.

I'm not sure the bug is caused by a mis-configuration in my code or if it's
a bug in nixpkgs, Cabal or GHC. Any idea what could be causing this?

Bas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Static data and RULES

[Bas van Dijk]

I also remember using such rules in my code. See for example:

https://github.com/basvandijk/aeson/blob/json-builder/Data/Aeson/Types/Internal.hs#L273

TIL rules like that are fragile.

Bas

Op 17 feb. 2017 3:49 p.m. schreef "David Feuer" :

I've never used such rules myself, but when I asked Duncan Coutts about
whether and how such rules were used in the wild, he said

> Well I've certainly tried to use that in the past.
> A previous version of the cbor lib which used a different
> representation did a lot of matching on constructors to re-arrange input
to
> an interpreter, until I discovered that GHC
> actually uses constructor wrappers and that matching on constructors was
> thus not reliable .

He described such rules as "a totally legit thing to want to do". If a
datatype represents an AST, then rewriting its terms can optimize the
constructed programs. Of course, it's ultimately up to you. I have no dog in
this race myself; my concern was for other people's code that could break
as a
result. Certainly such code is already fragile when strict constructors are
involved, but if people have cleverly figured out that lazy constructors are
more reliable in that regard, they could be using it. I don't know.

David

On Friday, February 17, 2017 8:06:17 AM EST Simon Peyton Jones via ghc-devs
wrote:
> {-# RULES   "L" LCon1 0 = LCon2
> Oh I missed this entirely. You want to write a rule FOR a data
> constructor   I thought you just meant one that matches on a data
> constructor.
 That is you want (L 0) to rewrite, all by itself, to LCon2?
> That had never occurred to me as a possibility.  Bizarre. Let’s not do
> that.
>
> · GHC does not (knowingly) support it today
>
> · It is a deeply weird thing to do
>
> · If you want to do it, write you own “smart constructor” mkLCon1,
> that inlines when you say

> mkLCon1 x = LCon1 x
>
> {-# INILNE [0] mkLCon1 #-}
>
> {-# RULES “L” mkLCon1 x = LCon2 #-}
>
>
> Problem solved.
> Simon
>
> From: David Feuer [mailto:david.fe...@gmail.com]
> Sent: 17 February 2017 00:30
> To: Simon Peyton Jones 
> Cc: ghc-devs ; Reid Barton ; Ben
> Gamari 
 Subject: RE: Static data and RULES
>
> Let me give an example. Suppose we have
>
> data L = LCon1 Int | LCon2
> data S = SCon !Int
>
> {-# RULES
> "L" LCon1 0 = LCon2
> "S" forall x . f (SCon x) = g x
>  #-}
>
> The immediate problem today is with "S". The SCon wrapper could very well
> inline before the rule has a chance to fire. We'd like to be able to phase
> that inline to give it a chance.

> The "L" rule becomes problematic when we try to identify static data the
> simplifier shouldn't have to try to optimize. If it identifies LCon 0 as
> static, the "L" rule will never fire.

> On Feb 16, 2017 7:08 PM, "David Feuer"
> > wrote:
 Semantically,
> the proposed scheme is very nearly equivalent to breaking *every* data
> constructor into a worker and a wrapper, and allowing INLINE and NOINLINE
> pragmas on the wrappers. That would allow terms built only from
constructor
> workers and literals to be identified as they're constructed in any stage
> and left alone by the simplifier. It would also allow people using RULES
> that match on constructors to make those work reliably, by making sure the
> bindings they match on don't inline away or get marked static too early.
Of
> course, we don't actually need to add more worker/wrapper pairs to do
this;
> we can fake that.
> On Feb 16, 2017 6:53 PM, "Simon Peyton Jones"
> > wrote:
 I’m sorry I
> still don’t understand the problem.  Can you give an example?  It all
works
> fine today; what will change in the proposed new scheme.  Indeed what IS
> the proposed new scheme?
> I’m lost
>
> Simon
>
> From: David Feuer
> [mailto:david.fe...@gmail.com]
 Sent: 16
> February 2017 23:51
> To: Simon Peyton Jones
> >
 Cc: ghc-devs
> >; Reid Barton
> >; Ben Gamari
> > Subject: RE: Static data and
> RULES
>
> Sorry; guess I should have given more background on that. This goes back
to
> the performance problems Ben encountered in Typeable. The goal is to avoid
> trying to optimize something over and over that's never ever going to
> change. If we know that a term is made only of static data, we can skip it
> altogether in simplification. Suppose we have

> foo = Just (Right [1])
>
> Then no amount of optimization will ever be useful. But what about RULES?
If
> the outermost pattern in a rule matches on a data constructor, then it's
> not static anymore! We may be replacing it with something else. So we need
> a finer mechanism. We *also* need a finer mechanism 

Re: One-shot semantics in GHC event manager

[Bas van Dijk]

Hi Ben, Austin,

Is there any chance of Ben's event manager patch landing in GHC-7.8.4?

Bas

On 13 October 2014 21:05, Ben Gamari bgamari.f...@gmail.com wrote:
 Ben Gamari bgamari.f...@gmail.com writes:

 Andreas Voellmy andreas.voel...@gmail.com writes:

 On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari bgamari.f...@gmail.com wrote:

 Ah... so this is not useful to you. I guess we could add `loop` to
 GHC.Event's export list. On the other hand, I like your LifeTime proposal
 better and then no one needs `loop`, so let's try this first.

 I have a first cut of this here [1]. It compiles but would be I shocked
 if it ran. All of the pieces are there but I need to change
 EventLifetime to a more efficient encoding (there's no reason why it
 needs to be more than an Int).

 As it turns out the patch seems to get through the testsuite after a few
 minor fixes.

 What other tests can I subject this to? I'm afraid I don't have the
 access to any machine even close to the size of those that the original
 event manager was tested on so checking for performance regressions will
 be difficult.

 Cheers,

 - Ben

 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs