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: GitLab cross-posting to Trac?

[Simon Peyton Jones via ghc-devs]

It's **super-helpful** that the Trac ticket includes, as a comment, the 
commit(s) that fixed it. Please can this happen with Gitlab too?

Otherwise, when looking at the ticket two years later there is literally no 
clue what commit (if any) fixed it.

If it can't be done automatically, it must be done manually by each person 
making a commit.  Which is terribly painful.  (esp since it can only be done 
post-CI.)

Thanks

Simon

| -Original Message-
| From: ghc-devs  On Behalf Of Ben Gamari
| Sent: 04 January 2019 21:33
| To: Richard Eisenberg ; GHC 
| Subject: Re: GitLab cross-posting to Trac?
| 
| Richard Eisenberg  writes:
| 
| > Hi devs,
| >
| > With our new GitLab workflow, will commit messages still be posted to
| > Issues (once the migration is complete)? That's been really useful
| > with Trac.
| >
| GitLab does not post the commit message to the issues it mentions. It
| does create a link to the commit but this doesn't include the commit
| message. We could change this with a daemon if we think this would be
| helpful.
| 
| Cheers,
| 
| - Ben

___
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

[Adam Sandberg Eriksson]

A ticket which seems to cover the same problem: 
https://ghc.haskell.org/trac/ghc/ticket/11829


—Adam

> On 4 Jan 2019, at 16:50, Bas van Dijk  wrote:
> 
> 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

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

Re: GitLab cross-posting to Trac?

[Ben Gamari]

Richard Eisenberg  writes:

> Hi devs,
>
> With our new GitLab workflow, will commit messages still be posted to
> Issues (once the migration is complete)? That's been really useful
> with Trac.
>
GitLab does not post the commit message to the issues it mentions. It
does create a link to the commit but this doesn't include the commit
message. We could change this with a daemon if we think this would be
helpful.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab pain

[Ben Gamari]

On January 4, 2019 2:17:45 PM EST, Artem Pelenitsyn  
wrote:
>It seems you'd want the "Toggle All" button. There is an issue for
>that:
>
>https://gitlab.com/gitlab-org/gitlab-ce/issues/19149
>

Precisely. Thank you for finding this. 

Cheers, 

- Ben 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: The GHC Proposals Process

[Eric Seidel]

I've thought about this a little. The only advantage I can think of is that 
moving to GitLab would make it easier to cross-reference other GHC issues. 

For example, in the record-set-field proposal[1] people have referenced a few 
different Trac tickets. Sometimes the reference includes a link to the ticket 
and sometimes it's just "#1234". GitHub (and I hope GitLab) has a nice feature 
that automatically renders references to other issues as links. It works across 
projects too, and the comment editor helps you search for the correct issue 
while typing.

This would be a nice convenience, but I'm not sure if it pulls its weight in 
comparison to the greater visibility of GitHub.

Eric

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/158

On Fri, Jan 4, 2019, at 13:56, Ben Gamari wrote:
> On January 4, 2019 12:56:58 PM EST, Ara Adkins  wrote:
> >Hey All,
> >
> >Now we have our own git instance in GitLab, are there any plans to move
> >the
> >proposals process from GitHub?
> >
> >_ara
> 
> I haven't considered the possibility of moving the proposal process and 
> I'm not sure I see a compelling reason to do so. I would be happy to 
> consider arguments otherwise but it seems to me that the process is 
> running reasonably well on GitHub and benefits from the broad reach that 
> GitHub provides.
> 
> Cheers,
> 
> - Ben 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab pain

[Artem Pelenitsyn]

It seems you'd want the "Toggle All" button. There is an issue for that:

https://gitlab.com/gitlab-org/gitlab-ce/issues/19149

There is even a beautiful workaround given there with typing the following
command in the JavaScript console in a browser:
$(".discussion-toggle-button:has(i.fa-chevron-down)").click()
After that, indeed, I could Ctrl+F the phrase referenced by Simon ("Another
module should reference the symbol") while before I could not.

--
Best, Artem

On Fri, 4 Jan 2019 at 21:48 Ben Gamari  wrote:

> Quite right. I will bring this up with upstream.
>
> On January 4, 2019 1:04:43 PM EST, Brandon Allbery 
> wrote:
>>
>> On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari  wrote:
>>
>>> As mentioned by others, discussions that have been marked as "resolved"
>>> are collapsed by default. If you search for the text "Toggle discussion"
>>> you will find that the collapsed discussions have link on their
>>> right-hand side which you can click on to expand the hidden comments.
>>>
>>
>> The problem there being there's a lot of such, and no way to tell which
>> one is relevant unless you have both original links and enough context.
>> Finding stuff like that absent context doesn't look at all easy. :/
>>
>> --
>> brandon s allbery kf8nh
>> allber...@gmail.com
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: The GHC Proposals Process

[Ara Adkins]

I certainly have no compelling reasons to do so! It was more a question than 
anything else, as I happen to agree that the reach of GitHub is beneficial in 
this case! 

_ara

> On 4 Jan 2019, at 18:56, Ben Gamari  wrote:
> 
>> On January 4, 2019 12:56:58 PM EST, Ara Adkins  wrote:
>> Hey All,
>> 
>> Now we have our own git instance in GitLab, are there any plans to move
>> the
>> proposals process from GitHub?
>> 
>> _ara
> 
> I haven't considered the possibility of moving the proposal process and I'm 
> not sure I see a compelling reason to do so. I would be happy to consider 
> arguments otherwise but it seems to me that the process is running reasonably 
> well on GitHub and benefits from the broad reach that GitHub provides.
> 
> Cheers,
> 
> - Ben 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: The GHC Proposals Process

[Ben Gamari]

On January 4, 2019 12:56:58 PM EST, Ara Adkins  wrote:
>Hey All,
>
>Now we have our own git instance in GitLab, are there any plans to move
>the
>proposals process from GitHub?
>
>_ara

I haven't considered the possibility of moving the proposal process and I'm not 
sure I see a compelling reason to do so. I would be happy to consider arguments 
otherwise but it seems to me that the process is running reasonably well on 
GitHub and benefits from the broad reach that GitHub provides.

Cheers,

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

Re: Gitlab pain

[Ben Gamari]

Quite right. I will bring this up with upstream. 

On January 4, 2019 1:04:43 PM EST, Brandon Allbery  wrote:
>On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari  wrote:
>
>> As mentioned by others, discussions that have been marked as
>"resolved"
>> are collapsed by default. If you search for the text "Toggle
>discussion"
>> you will find that the collapsed discussions have link on their
>> right-hand side which you can click on to expand the hidden comments.
>>
>
>The problem there being there's a lot of such, and no way to tell which
>one
>is relevant unless you have both original links and enough context.
>Finding
>stuff like that absent context doesn't look at all easy. :/
>
>-- 
>brandon s allbery kf8nh
>allber...@gmail.com

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab: Cmd+Enter considered harmful on reviews

[Richard Eisenberg]

I'm on Firefox.

It doesn't matter all that much, really. I was hoping that a review was its own 
thing. But GitLab doesn't do that: a review is just a set of comments all 
delivered at the same time. Now that I've posted my review, my comments have 
become 49 separate "discussions". Oof.

Richard

> On Jan 4, 2019, at 1:09 PM, Ben Gamari  wrote:
> 
> Richard Eisenberg  writes:
> 
>> PSA: When reviewing an MR on GitLab, every comment has two buttons:
>> (1) add to review, and (2) add comment now. Cmd+Enter (on my machine
>> at least), does option (2), even though option (1) is bold and green.
>> This is not what I wanted. (By the way, "comments" actually open these
>> things called "discussions", which can be resolved. But that's another
>> matter.)
>> 
> Hmm, strange. I can't seem to reproduce this. Which browser are you
> using?
> 
> Cheers,
> 
> - Ben
> 

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

Re: GitLab: Cmd+Enter considered harmful on reviews

[Ben Gamari]

Richard Eisenberg  writes:

> PSA: When reviewing an MR on GitLab, every comment has two buttons:
> (1) add to review, and (2) add comment now. Cmd+Enter (on my machine
> at least), does option (2), even though option (1) is bold and green.
> This is not what I wanted. (By the way, "comments" actually open these
> things called "discussions", which can be resolved. But that's another
> matter.)
>
Hmm, strange. I can't seem to reproduce this. Which browser are you
using?

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Gitlab pain

[Ben Gamari]

Simon Peyton Jones via ghc-devs  writes:

> |  The Discussion tab is ground truth for comments in that you won't miss any
> |  if you look through it, but it gets cluttered.
>
> Apparently not.  Check out
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10
> and search for "Another module should reference the symbol" which is 
> definitely in a comment.
>
> Maybe I'm missing something.
>
My apologies for the slow reply. I've been a bit under the weather this
week; there has been a lot of time spent on the couch.

As mentioned by others, discussions that have been marked as "resolved"
are collapsed by default. If you search for the text "Toggle discussion"
you will find that the collapsed discussions have link on their
right-hand side which you can click on to expand the hidden comments.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

The GHC Proposals Process

[Ara Adkins]

Hey All,

Now we have our own git instance in GitLab, are there any plans to move the
proposals process from GitHub?

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

RE: Gitlab pain

[Simon Peyton Jones via ghc-devs]

|  The Discussion tab is ground truth for comments in that you won't miss any
|  if you look through it, but it gets cluttered.

Apparently not.  Check out
https://gitlab.haskell.org/ghc/ghc/merge_requests/10
and search for "Another module should reference the symbol" which is definitely 
in a comment.

Maybe I'm missing something.

Simon

|  -Original Message-
|  From: Evan Laforge 
|  Sent: 04 January 2019 17:13
|  To: Richard Eisenberg 
|  Cc: Simon Peyton Jones ; ghc-devs 
|  Subject: Re: Gitlab pain
|  
|  The diff in
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
|  skell.org%2Fghc%2Fghc%2Fmerge_requests%2F10%2Fdiffsdata=02%7C01%7Csimo
|  npj%40microsoft.com%7C13d19e5c0e4c4398715a08d67267f643%7C72f988bf86f141af91
|  ab2d7cd011db47%7C1%7C0%7C636822188176178183sdata=wJWw5HxSWePGKWWZYEPbr
|  dWrhADmIWHalekobnEgiTo%3Dreserved=0
|  is the ground truth for the source code.  However, it's not ground truth
|  for comments.  You only get to see the ones attached to the revisions
|  selected in "Changes between x and y", which means they tend to get lost.
|  The Discussion tab is ground truth for comments in that you won't miss any
|  if you look through it, but it gets cluttered.
|  There should be a "skip to first unresolved comment" button, which helps.
|  I wish it let you cycle them instead of always going to the first.  But the
|  discussion tab is not good for seeing what the change being discussed
|  actually is, so you have to go back to Changes, at which point you lose
|  your place in Discussion.
|  
|  If anyone knows a better way to do comments I'd also like to know... I use
|  gitlab at work and find it pretty awkward for medium-and-up sized reviews.
|  
|  On Sat, Jan 5, 2019 at 12:25 AM Richard Eisenberg 
|  wrote:
|  >
|  > GitLab groups posts on lines in MRs as "discussions". A discussion can
|  > be *resolved*. When it is resolved, the discussion is collapsed by
|  > default when you view the MR. The particular comment you're seeking
|  > can be found on the MR if you open the discussion you started at
|  > 10:04am this morning (GMT) and that Gabor closed at 2:10pm this
|  > afternoon. (I'm already missing comment numbers like in Trac.)
|  >
|  > I'm still learning my way around, too, so correct me (anyone) if there's
|  a better way to describe all this.
|  >
|  > Richard
|  >
|  > On Jan 4, 2019, at 11:19 AM, Simon Peyton Jones via ghc-devs  wrote:
|  >
|  > I’m getting lost in a maze of twisty little passages, all alike.
|  >
|  > I’m looking at
|  >
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F10%23note_1877data=
|  > 02%7C01%7Csimonpj%40microsoft.com%7C13d19e5c0e4c4398715a08d67267f643%7
|  > C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636822188176178183sda
|  > ta=ht6hBYw5rfjSMmpYsmwNnyhxEvHIdjyy%2FLqA2FB1dC8%3Dreserved=0
|  >
|  > and
|  >
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > ab.haskell.org%2Fghc%2Fghc%2Fmerge_requests%2F10data=02%7C01%7Csi
|  > monpj%40microsoft.com%7C13d19e5c0e4c4398715a08d67267f643%7C72f988bf86f
|  > 141af91ab2d7cd011db47%7C1%7C0%7C636822188176188191sdata=1N2eoL7dC
|  > 8ElWQ6zyAW4wXBQcaRv4bCk%2FnrrKS%2BlLfI%3Dreserved=0
|  >
|  >
|  >
|  > But the note in the former starting “Another module should reference the
|  symbol…” doesn’t show up in the latter, anywhere.
|  >
|  > How can I see the current state of play on this MR, the ground truth?
|  >
|  > Simon
|  >
|  > ___
|  > ghc-devs mailing list
|  > ghc-devs@haskell.org
|  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devsdata=02%7C01
|  > %7Csimonpj%40microsoft.com%7C13d19e5c0e4c4398715a08d67267f643%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636822188176188191sdata=PJj9
|  > 2UnmQNNeCFVTt1d8XWSVCcuSAalMJsq152DEfqA%3Dreserved=0
|  >
|  >
|  > ___
|  > ghc-devs mailing list
|  > ghc-devs@haskell.org
|  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devsdata=02%7C01
|  > %7Csimonpj%40microsoft.com%7C13d19e5c0e4c4398715a08d67267f643%7C72f988
|  > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636822188176188191sdata=PJj9
|  > 2UnmQNNeCFVTt1d8XWSVCcuSAalMJsq152DEfqA%3Dreserved=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab pain

[Evan Laforge]

The diff in https://gitlab.haskell.org/ghc/ghc/merge_requests/10/diffs
is the ground truth for the source code.  However, it's not ground
truth for comments.  You only get to see the ones attached to the
revisions selected in "Changes between x and y", which means they tend
to get lost.  The Discussion tab is ground truth for comments in that
you won't miss any if you look through it, but it gets cluttered.
There should be a "skip to first unresolved comment" button, which
helps.  I wish it let you cycle them instead of always going to the
first.  But the discussion tab is not good for seeing what the change
being discussed actually is, so you have to go back to Changes, at
which point you lose your place in Discussion.

If anyone knows a better way to do comments I'd also like to know... I
use gitlab at work and find it pretty awkward for medium-and-up sized
reviews.

On Sat, Jan 5, 2019 at 12:25 AM Richard Eisenberg  wrote:
>
> GitLab groups posts on lines in MRs as "discussions". A discussion can be 
> *resolved*. When it is resolved, the discussion is collapsed by default when 
> you view the MR. The particular comment you're seeking can be found on the MR 
> if you open the discussion you started at 10:04am this morning (GMT) and that 
> Gabor closed at 2:10pm this afternoon. (I'm already missing comment numbers 
> like in Trac.)
>
> I'm still learning my way around, too, so correct me (anyone) if there's a 
> better way to describe all this.
>
> Richard
>
> On Jan 4, 2019, at 11:19 AM, Simon Peyton Jones via ghc-devs 
>  wrote:
>
> I’m getting lost in a maze of twisty little passages, all alike.
>
> I’m looking at
>
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877
>
> and
>
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10
>
>
>
> But the note in the former starting “Another module should reference the 
> symbol…” doesn’t show up in the latter, anywhere.
>
> How can I see the current state of play on this MR, the ground truth?
>
> Simon
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Gitlab pain

[Simon Peyton Jones via ghc-devs]

Thanks.  But I cannot work out

  *   How to find this “collapsed” discussion
  *   How to un-collapse it
  *   How to search for stuff in collapsed discussions. (Finding them one at a 
time, uncollapsing, and searching, seems wrong.)  How can I un-collapse 
everything?
Simon


From: Richard Eisenberg 
Sent: 04 January 2019 16:26
To: Simon Peyton Jones 
Cc: ghc-devs 
Subject: Re: Gitlab pain

GitLab groups posts on lines in MRs as "discussions". A discussion can be 
*resolved*. When it is resolved, the discussion is collapsed by default when 
you view the MR. The particular comment you're seeking can be found on the MR 
if you open the discussion you started at 10:04am this morning (GMT) and that 
Gabor closed at 2:10pm this afternoon. (I'm already missing comment numbers 
like in Trac.)

I'm still learning my way around, too, so correct me (anyone) if there's a 
better way to describe all this.

Richard


On Jan 4, 2019, at 11:19 AM, Simon Peyton Jones via ghc-devs 
mailto:ghc-devs@haskell.org>> wrote:

I’m getting lost in a maze of twisty little passages, all alike.
I’m looking at
https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877
and
https://gitlab.haskell.org/ghc/ghc/merge_requests/10

But the note in the former starting “Another module should reference the 
symbol…” doesn’t show up in the latter, anywhere.
How can I see the current state of play on this MR, the ground truth?
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

GitLab: Cmd+Enter considered harmful on reviews

[Richard Eisenberg]

PSA: When reviewing an MR on GitLab, every comment has two buttons: (1) add to 
review, and (2) add comment now. Cmd+Enter (on my machine at least), does 
option (2), even though option (1) is bold and green. This is not what I 
wanted. (By the way, "comments" actually open these things called 
"discussions", which can be resolved. But that's another matter.)

I've now removed all my comments and added them to my review. But I wanted you 
all to know about this in case you stumble across the same problem.

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

Re: Gitlab pain

[Richard Eisenberg]

GitLab groups posts on lines in MRs as "discussions". A discussion can be 
*resolved*. When it is resolved, the discussion is collapsed by default when 
you view the MR. The particular comment you're seeking can be found on the MR 
if you open the discussion you started at 10:04am this morning (GMT) and that 
Gabor closed at 2:10pm this afternoon. (I'm already missing comment numbers 
like in Trac.)

I'm still learning my way around, too, so correct me (anyone) if there's a 
better way to describe all this.

Richard

> On Jan 4, 2019, at 11:19 AM, Simon Peyton Jones via ghc-devs 
>  wrote:
> 
> I’m getting lost in a maze of twisty little passages, all alike.
> 
> I’m looking at
> 
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877 
> 
> and
> 
> https://gitlab.haskell.org/ghc/ghc/merge_requests/10 
> 
>  
> 
> But the note in the former starting “Another module should reference the 
> symbol…” doesn’t show up in the latter, anywhere. 
> 
> How can I see the current state of play on this MR, the ground truth?
> 
> Simon
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Gitlab pain

[Simon Peyton Jones via ghc-devs]

I'm getting lost in a maze of twisty little passages, all alike.
I'm looking at
https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877
and
https://gitlab.haskell.org/ghc/ghc/merge_requests/10

But the note in the former starting "Another module should reference the 
symbol..." doesn't show up in the latter, anywhere.
How can I see the current state of play on this MR, the ground truth?
Simon
___
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

Re: Default options for -threaded

[Carter Schonwald]

Yup! Let’s do it. Efficient io and compute during ffi computation sound
good to me

On Fri, Jan 4, 2019 at 10:22 AM Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> Two years seems a good amount of time for any objectors.
>
> https://ghc.haskell.org/trac/ghc/ticket/16126#ticket
>
> On Fri, Oct 21, 2016 at 5:35 PM Simon Marlow  wrote:
> >
> > On 8 October 2016 at 17:55, Ben Gamari  wrote:
> >>
> >> loneti...@gmail.com writes:
> >>
> >> > Hi All,
> >> >
> >> > A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why
> >> > -N -qa isn’t the default for -threaded.
> >> >
> >> I'm not sure that scheduling on all of the cores on the user's machine
> by
> >> default is a good idea, especially given that our users have
> >> learned to expect the existing default. Enabling affinity by default
> >> seems reasonable if we have evidence that it helps the majority of
> >> applications, but we would first need to introduce an additional
> >> flag to disable it.
> >
> >
> > Affinity is almost always a bad idea in my experience.
> >
> >>
> >> In general I think -N1 is a reasonable default as it acknowledges the
> >> fact that deploying parallelism is not something that can be done
> >> blindly in many (most?) applications. To make effective use of
> >> parallelism the user needs to understand their hardware, their
> >> application, and its interaction with the runtime system and configure
> >> the RTS appropriately.
> >>
> >
> > Agree on keeping -N1.
> >
> > Related to this, I think it's about time we made -threaded the default.
> We could add a -single-threaded option to get back the old behaviour.
> >
> > There is a small overhead to using -threaded, but -threaded is also
> required to make a lot of things work (e.g. waitForProcess in a
> multithreaded program, not to mention parallelism).
> >
> > Anyone interested in doing this?
> >
> > Cheers
> > Simon
> >
> >
> >>
> >> Of course, this is just my two-cents.
> >>
> >> Cheers,
> >>
> >> - Ben
> >>
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type family equation violates injectivity?

[Carter Schonwald]

Ok, either way it might be nice to just make it a minor bump.  I’ll see
what I can do :)

On Fri, Jan 4, 2019 at 10:09 AM Alexander V Vershilov <
alexander.vershi...@gmail.com> wrote:

> I can't answer your question before I will port inline-r to the newer
> vector. I would prefer to support both version and keep CPP around, like
> you suggested, but the answer depends on the amount of changes I need to
> keep. If that would be few lines of code then I'll go with that, in the
> side if the amount of changes will be comparable with a module size, then
> I'd prefer to cut out older versions.
>
> On Fri, Jan 4, 2019, 18:04 Carter Schonwald  wrote:
>
>> Would it be easier if you can do a conjunction on vector and base version
>> in your cpp should you want to support both sides ?
>>
>> On Fri, Jan 4, 2019 at 9:59 AM Alexander V Vershilov <
>> alexander.vershi...@gmail.com> wrote:
>>
>>> For inline-r we have added a revision that sets upper limit, so now
>>> hackage and stackage should both be happy. I'm not sure if any Linux
>>> distribution provides inline-r as a package but that should be normal
>>> situation for them. Next version will either set lower dependency boundary
>>> or will keep a code that will run with both APIs. So from my perspective
>>> any solution (even keeping things as-is) will be ok.
>>>
>>>
>>> On Fri, Jan 4, 2019, 17:31 Carter Schonwald >> wrote:
>>>
 Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
 bump and make the bug fix bump version unbuildable.

 Would this help matters ?

 On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald <
 carter.schonw...@gmail.com> wrote:

> Yeah, I later found it impacted one of my own pieces of code too, in
> that I needed to make still further type families injective.
>
> I do think that a lot of vectors current module structure reflects a
> desire for injectivity coupled with historical a lack of mechanism for
> guaranteeing it.
>
> Mess up on my part for sure.  :)
>
> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu  wrote:
>
>> Hi Carter,
>>
>> thanks for looking into this. We were initially surprised to see a
>> breaking change in a point release, but no biggy. It's pretty hard to 
>> offer
>> strong stability guarantees without automated tooling to catch this kind 
>> of
>> thing, and these things happen. We'll patch up HaskellR shortly.
>>
>> Best,
>>
>>
>> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> To be clear : I’m annoyed with myself that this impacted a package
>>> that depends on vector, but this does seem to be the case that the 
>>> newest
>>> bug fix release for vector actually revealed a broken design for the 
>>> vector
>>> instances / data types in the inline-r package.
>>>
>>> To;dr — I suggest patching inline-r to remove the s parameter in its
>>> immutable vector data types
>>>
>>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
>>> carter.schonw...@gmail.com> wrote:
>>>
 so i took a look .. (also the inline-r devs seem to have done a
 hackage revision so you wont hit that issue in your current setup if 
 you do
 a cabal update ..)
 and it seems like the type definitions in inline-r are kinda bogus
 and you should get them patched ...

 the MVector type class, and related type families, all assume your
 mutable type has the last two arguments as the io/state token and then 
 the
 element type

 eg
 basicLength :: v s a -> Int
 


 i looked at
 https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
 and



 as a point of grounding this chat
 the injective type familly in question is defined by the follwoing


 --#if MIN_VERSION_base(4,9,0)type family Mutable 
 
  (v 
 
  :: * -> *) = (mv 
 
  :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * 
 -> * -> *#endif

 anyways, it looks like the Pure / immutable vector data type in
 inline-r has a spurious state token argument in its definition that
 shouldn't be there, OR there need to be two "s" params in inline-r 
 instead
 

Re: Default options for -threaded

[Matthew Pickering]

Two years seems a good amount of time for any objectors.

https://ghc.haskell.org/trac/ghc/ticket/16126#ticket

On Fri, Oct 21, 2016 at 5:35 PM Simon Marlow  wrote:
>
> On 8 October 2016 at 17:55, Ben Gamari  wrote:
>>
>> loneti...@gmail.com writes:
>>
>> > Hi All,
>> >
>> > A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why
>> > -N -qa isn’t the default for -threaded.
>> >
>> I'm not sure that scheduling on all of the cores on the user's machine by
>> default is a good idea, especially given that our users have
>> learned to expect the existing default. Enabling affinity by default
>> seems reasonable if we have evidence that it helps the majority of
>> applications, but we would first need to introduce an additional
>> flag to disable it.
>
>
> Affinity is almost always a bad idea in my experience.
>
>>
>> In general I think -N1 is a reasonable default as it acknowledges the
>> fact that deploying parallelism is not something that can be done
>> blindly in many (most?) applications. To make effective use of
>> parallelism the user needs to understand their hardware, their
>> application, and its interaction with the runtime system and configure
>> the RTS appropriately.
>>
>
> Agree on keeping -N1.
>
> Related to this, I think it's about time we made -threaded the default.  We 
> could add a -single-threaded option to get back the old behaviour.
>
> There is a small overhead to using -threaded, but -threaded is also required 
> to make a lot of things work (e.g. waitForProcess in a multithreaded program, 
> not to mention parallelism).
>
> Anyone interested in doing this?
>
> Cheers
> Simon
>
>
>>
>> Of course, this is just my two-cents.
>>
>> Cheers,
>>
>> - Ben
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type family equation violates injectivity?

[Alexander V Vershilov]

I can't answer your question before I will port inline-r to the newer
vector. I would prefer to support both version and keep CPP around, like
you suggested, but the answer depends on the amount of changes I need to
keep. If that would be few lines of code then I'll go with that, in the
side if the amount of changes will be comparable with a module size, then
I'd prefer to cut out older versions.

On Fri, Jan 4, 2019, 18:04 Carter Schonwald  Would it be easier if you can do a conjunction on vector and base version
> in your cpp should you want to support both sides ?
>
> On Fri, Jan 4, 2019 at 9:59 AM Alexander V Vershilov <
> alexander.vershi...@gmail.com> wrote:
>
>> For inline-r we have added a revision that sets upper limit, so now
>> hackage and stackage should both be happy. I'm not sure if any Linux
>> distribution provides inline-r as a package but that should be normal
>> situation for them. Next version will either set lower dependency boundary
>> or will keep a code that will run with both APIs. So from my perspective
>> any solution (even keeping things as-is) will be ok.
>>
>>
>> On Fri, Jan 4, 2019, 17:31 Carter Schonwald > wrote:
>>
>>> Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
>>> bump and make the bug fix bump version unbuildable.
>>>
>>> Would this help matters ?
>>>
>>> On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald <
>>> carter.schonw...@gmail.com> wrote:
>>>
 Yeah, I later found it impacted one of my own pieces of code too, in
 that I needed to make still further type families injective.

 I do think that a lot of vectors current module structure reflects a
 desire for injectivity coupled with historical a lack of mechanism for
 guaranteeing it.

 Mess up on my part for sure.  :)

 On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu  wrote:

> Hi Carter,
>
> thanks for looking into this. We were initially surprised to see a
> breaking change in a point release, but no biggy. It's pretty hard to 
> offer
> strong stability guarantees without automated tooling to catch this kind 
> of
> thing, and these things happen. We'll patch up HaskellR shortly.
>
> Best,
>
>
> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> To be clear : I’m annoyed with myself that this impacted a package
>> that depends on vector, but this does seem to be the case that the newest
>> bug fix release for vector actually revealed a broken design for the 
>> vector
>> instances / data types in the inline-r package.
>>
>> To;dr — I suggest patching inline-r to remove the s parameter in its
>> immutable vector data types
>>
>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> so i took a look .. (also the inline-r devs seem to have done a
>>> hackage revision so you wont hit that issue in your current setup if 
>>> you do
>>> a cabal update ..)
>>> and it seems like the type definitions in inline-r are kinda bogus
>>> and you should get them patched ...
>>>
>>> the MVector type class, and related type families, all assume your
>>> mutable type has the last two arguments as the io/state token and then 
>>> the
>>> element type
>>>
>>> eg
>>> basicLength :: v s a -> Int
>>> 
>>>
>>>
>>> i looked at
>>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>>> and
>>>
>>>
>>>
>>> as a point of grounding this chat
>>> the injective type familly in question is defined by the follwoing
>>>
>>>
>>> --#if MIN_VERSION_base(4,9,0)type family Mutable 
>>> 
>>>  (v 
>>> 
>>>  :: * -> *) = (mv 
>>> 
>>>  :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * 
>>> -> * -> *#endif
>>>
>>> anyways, it looks like the Pure / immutable vector data type in
>>> inline-r has a spurious state token argument in its definition that
>>> shouldn't be there, OR there need to be two "s" params in inline-r 
>>> instead
>>> of the one
>>>
>>> heres the full code i linked to in question
>>>
>>>
>>> -- | Mutable R vector. Represented in memory with the same header
>>> as 'SEXP'
>>>
>>> -- nodes. The second type parameter is phantom, reflecting at the
>>> type level the
>>> -- tag of the vector when 

Re: Type family equation violates injectivity?

[Carter Schonwald]

Would it be easier if you can do a conjunction on vector and base version
in your cpp should you want to support both sides ?

On Fri, Jan 4, 2019 at 9:59 AM Alexander V Vershilov <
alexander.vershi...@gmail.com> wrote:

> For inline-r we have added a revision that sets upper limit, so now
> hackage and stackage should both be happy. I'm not sure if any Linux
> distribution provides inline-r as a package but that should be normal
> situation for them. Next version will either set lower dependency boundary
> or will keep a code that will run with both APIs. So from my perspective
> any solution (even keeping things as-is) will be ok.
>
>
> On Fri, Jan 4, 2019, 17:31 Carter Schonwald  wrote:
>
>> Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
>> bump and make the bug fix bump version unbuildable.
>>
>> Would this help matters ?
>>
>> On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> Yeah, I later found it impacted one of my own pieces of code too, in
>>> that I needed to make still further type families injective.
>>>
>>> I do think that a lot of vectors current module structure reflects a
>>> desire for injectivity coupled with historical a lack of mechanism for
>>> guaranteeing it.
>>>
>>> Mess up on my part for sure.  :)
>>>
>>> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu  wrote:
>>>
 Hi Carter,

 thanks for looking into this. We were initially surprised to see a
 breaking change in a point release, but no biggy. It's pretty hard to offer
 strong stability guarantees without automated tooling to catch this kind of
 thing, and these things happen. We'll patch up HaskellR shortly.

 Best,


 On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
 carter.schonw...@gmail.com> wrote:

> To be clear : I’m annoyed with myself that this impacted a package
> that depends on vector, but this does seem to be the case that the newest
> bug fix release for vector actually revealed a broken design for the 
> vector
> instances / data types in the inline-r package.
>
> To;dr — I suggest patching inline-r to remove the s parameter in its
> immutable vector data types
>
> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> so i took a look .. (also the inline-r devs seem to have done a
>> hackage revision so you wont hit that issue in your current setup if you 
>> do
>> a cabal update ..)
>> and it seems like the type definitions in inline-r are kinda bogus
>> and you should get them patched ...
>>
>> the MVector type class, and related type families, all assume your
>> mutable type has the last two arguments as the io/state token and then 
>> the
>> element type
>>
>> eg
>> basicLength :: v s a -> Int
>> 
>>
>>
>> i looked at
>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>> and
>>
>>
>>
>> as a point of grounding this chat
>> the injective type familly in question is defined by the follwoing
>>
>>
>> --#if MIN_VERSION_base(4,9,0)type family Mutable 
>> 
>>  (v 
>> 
>>  :: * -> *) = (mv 
>> 
>>  :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> 
>> * -> *#endif
>>
>> anyways, it looks like the Pure / immutable vector data type in
>> inline-r has a spurious state token argument in its definition that
>> shouldn't be there, OR there need to be two "s" params in inline-r 
>> instead
>> of the one
>>
>> heres the full code i linked to in question
>>
>>
>> -- | Mutable R vector. Represented in memory with the same header as
>> 'SEXP'
>>
>> -- nodes. The second type parameter is phantom, reflecting at the
>> type level the
>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector
>> and the
>> -- representation type are related via 'ElemRep'.
>> data MVector s ty a = MVector
>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
>> , mvectorOffset :: {-# UNPACK #-} !Int32
>> , mvectorLength :: {-# UNPACK #-} !Int32
>> }
>> -- | Internal wrapper type for reflection. First type parameter is
>> the reified
>> -- type to reflect.
>> newtype W t ty s a = W { unW :: MVector s ty a }
>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t
>> ty) a where

Re: Type family equation violates injectivity?

[Alexander V Vershilov]

For inline-r we have added a revision that sets upper limit, so now hackage
and stackage should both be happy. I'm not sure if any Linux distribution
provides inline-r as a package but that should be normal situation for
them. Next version will either set lower dependency boundary or will keep a
code that will run with both APIs. So from my perspective any solution
(even keeping things as-is) will be ok.

On Fri, Jan 4, 2019, 17:31 Carter Schonwald  Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
> bump and make the bug fix bump version unbuildable.
>
> Would this help matters ?
>
> On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> Yeah, I later found it impacted one of my own pieces of code too, in that
>> I needed to make still further type families injective.
>>
>> I do think that a lot of vectors current module structure reflects a
>> desire for injectivity coupled with historical a lack of mechanism for
>> guaranteeing it.
>>
>> Mess up on my part for sure.  :)
>>
>> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu  wrote:
>>
>>> Hi Carter,
>>>
>>> thanks for looking into this. We were initially surprised to see a
>>> breaking change in a point release, but no biggy. It's pretty hard to offer
>>> strong stability guarantees without automated tooling to catch this kind of
>>> thing, and these things happen. We'll patch up HaskellR shortly.
>>>
>>> Best,
>>>
>>>
>>> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
>>> carter.schonw...@gmail.com> wrote:
>>>
 To be clear : I’m annoyed with myself that this impacted a package that
 depends on vector, but this does seem to be the case that the newest bug
 fix release for vector actually revealed a broken design for the vector
 instances / data types in the inline-r package.

 To;dr — I suggest patching inline-r to remove the s parameter in its
 immutable vector data types

 On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
 carter.schonw...@gmail.com> wrote:

> so i took a look .. (also the inline-r devs seem to have done a
> hackage revision so you wont hit that issue in your current setup if you 
> do
> a cabal update ..)
> and it seems like the type definitions in inline-r are kinda bogus
> and you should get them patched ...
>
> the MVector type class, and related type families, all assume your
> mutable type has the last two arguments as the io/state token and then the
> element type
>
> eg
> basicLength :: v s a -> Int
> 
>
>
> i looked at
> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
> and
>
>
>
> as a point of grounding this chat
> the injective type familly in question is defined by the follwoing
>
>
> --#if MIN_VERSION_base(4,9,0)type family Mutable 
> 
>  (v 
> 
>  :: * -> *) = (mv 
> 
>  :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> 
> * -> *#endif
>
> anyways, it looks like the Pure / immutable vector data type in
> inline-r has a spurious state token argument in its definition that
> shouldn't be there, OR there need to be two "s" params in inline-r instead
> of the one
>
> heres the full code i linked to in question
>
>
> -- | Mutable R vector. Represented in memory with the same header as
> 'SEXP'
>
> -- nodes. The second type parameter is phantom, reflecting at the type
> level the
> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector
> and the
> -- representation type are related via 'ElemRep'.
> data MVector s ty a = MVector
> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
> , mvectorOffset :: {-# UNPACK #-} !Int32
> , mvectorLength :: {-# UNPACK #-} !Int32
> }
> -- | Internal wrapper type for reflection. First type parameter is the
> reified
> -- type to reflect.
> newtype W t ty s a = W { unW :: MVector s ty a }
> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t
> ty) a where
>
> data Vector s (ty :: SEXPTYPE) a = Vector
> { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset ::
> {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
> }
>
>
> type instance G.Mutable (W t ty s) = Mutable.W t ty
> Anyways, the fix here is to remove the s param from the Pure version
> of W and "Sexp 

Re: Type family equation violates injectivity?

[Carter Schonwald]

Hrmmm.  Here’s what I’ll do: I’ll make the same release a minor version
bump and make the bug fix bump version unbuildable.

Would this help matters ?

On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald 
wrote:

> Yeah, I later found it impacted one of my own pieces of code too, in that
> I needed to make still further type families injective.
>
> I do think that a lot of vectors current module structure reflects a
> desire for injectivity coupled with historical a lack of mechanism for
> guaranteeing it.
>
> Mess up on my part for sure.  :)
>
> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu  wrote:
>
>> Hi Carter,
>>
>> thanks for looking into this. We were initially surprised to see a
>> breaking change in a point release, but no biggy. It's pretty hard to offer
>> strong stability guarantees without automated tooling to catch this kind of
>> thing, and these things happen. We'll patch up HaskellR shortly.
>>
>> Best,
>>
>>
>> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> To be clear : I’m annoyed with myself that this impacted a package that
>>> depends on vector, but this does seem to be the case that the newest bug
>>> fix release for vector actually revealed a broken design for the vector
>>> instances / data types in the inline-r package.
>>>
>>> To;dr — I suggest patching inline-r to remove the s parameter in its
>>> immutable vector data types
>>>
>>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
>>> carter.schonw...@gmail.com> wrote:
>>>
 so i took a look .. (also the inline-r devs seem to have done a hackage
 revision so you wont hit that issue in your current setup if you do a cabal
 update ..)
 and it seems like the type definitions in inline-r are kinda bogus  and
 you should get them patched ...

 the MVector type class, and related type families, all assume your
 mutable type has the last two arguments as the io/state token and then the
 element type

 eg
 basicLength :: v s a -> Int
 


 i looked at
 https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
 and



 as a point of grounding this chat
 the injective type familly in question is defined by the follwoing


 --#if MIN_VERSION_base(4,9,0)type family Mutable 
 
  (v 
 
  :: * -> *) = (mv 
 
  :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * 
 -> *#endif

 anyways, it looks like the Pure / immutable vector data type in
 inline-r has a spurious state token argument in its definition that
 shouldn't be there, OR there need to be two "s" params in inline-r instead
 of the one

 heres the full code i linked to in question


 -- | Mutable R vector. Represented in memory with the same header as
 'SEXP'

 -- nodes. The second type parameter is phantom, reflecting at the type
 level the
 -- tag of the vector when viewed as a 'SEXP'. The tag of the vector and
 the
 -- representation type are related via 'ElemRep'.
 data MVector s ty a = MVector
 { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
 , mvectorOffset :: {-# UNPACK #-} !Int32
 , mvectorLength :: {-# UNPACK #-} !Int32
 }
 -- | Internal wrapper type for reflection. First type parameter is the
 reified
 -- type to reflect.
 newtype W t ty s a = W { unW :: MVector s ty a }
 instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t ty)
 a where

 data Vector s (ty :: SEXPTYPE) a = Vector
 { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset ::
 {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
 }


 type instance G.Mutable (W t ty s) = Mutable.W t ty
 Anyways, the fix here is to remove the s param from the Pure version of
 W and "Sexp Vector"



 On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald <
 carter.schonw...@gmail.com> wrote:

> were you using the same version of vector in both setups?
>
> in the most recent  vector release  we made mutable type family
> injective in the vector package for ghc's that support it ...
>
> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi 
> wrote:
>
>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r package
>> I get the error "Type family equation violates injectivity
>> annotation," and
>> a type variable on the 

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

[Gabor Greif]

Hi Bas,

maybe some DWARF unwind tables are not correctly installed in OS X?

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

Cheers,

Gabor

On 1/4/19, Bas van Dijk  wrote:
> 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: Type family equation violates injectivity?

[Boespflug, Mathieu]

Hi Carter,

thanks for looking into this. We were initially surprised to see a breaking
change in a point release, but no biggy. It's pretty hard to offer strong
stability guarantees without automated tooling to catch this kind of thing,
and these things happen. We'll patch up HaskellR shortly.

Best,


On Sun, 30 Dec 2018 at 01:06, Carter Schonwald 
wrote:

> To be clear : I’m annoyed with myself that this impacted a package that
> depends on vector, but this does seem to be the case that the newest bug
> fix release for vector actually revealed a broken design for the vector
> instances / data types in the inline-r package.
>
> To;dr — I suggest patching inline-r to remove the s parameter in its
> immutable vector data types
>
> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> so i took a look .. (also the inline-r devs seem to have done a hackage
>> revision so you wont hit that issue in your current setup if you do a cabal
>> update ..)
>> and it seems like the type definitions in inline-r are kinda bogus  and
>> you should get them patched ...
>>
>> the MVector type class, and related type families, all assume your
>> mutable type has the last two arguments as the io/state token and then the
>> element type
>>
>> eg
>> basicLength :: v s a -> Int
>> 
>>
>>
>> i looked at
>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374
>> and
>>
>>
>>
>> as a point of grounding this chat
>> the injective type familly in question is defined by the follwoing
>>
>>
>> --#if MIN_VERSION_base(4,9,0)type family Mutable 
>> 
>>  (v 
>> 
>>  :: * -> *) = (mv 
>> 
>>  :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * -> * 
>> -> *#endif
>>
>> anyways, it looks like the Pure / immutable vector data type in inline-r
>> has a spurious state token argument in its definition that shouldn't be
>> there, OR there need to be two "s" params in inline-r instead of the one
>>
>> heres the full code i linked to in question
>>
>>
>> -- | Mutable R vector. Represented in memory with the same header as
>> 'SEXP'
>>
>> -- nodes. The second type parameter is phantom, reflecting at the type
>> level the
>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector and
>> the
>> -- representation type are related via 'ElemRep'.
>> data MVector s ty a = MVector
>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty)
>> , mvectorOffset :: {-# UNPACK #-} !Int32
>> , mvectorLength :: {-# UNPACK #-} !Int32
>> }
>> -- | Internal wrapper type for reflection. First type parameter is the
>> reified
>> -- type to reflect.
>> newtype W t ty s a = W { unW :: MVector s ty a }
>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t ty) a
>> where
>>
>> data Vector s (ty :: SEXPTYPE) a = Vector
>> { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset ::
>> {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32
>> }
>>
>>
>> type instance G.Mutable (W t ty s) = Mutable.W t ty
>> Anyways, the fix here is to remove the s param from the Pure version of W
>> and "Sexp Vector"
>>
>>
>>
>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> were you using the same version of vector in both setups?
>>>
>>> in the most recent  vector release  we made mutable type family
>>> injective in the vector package for ghc's that support it ...
>>>
>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi 
>>> wrote:
>>>
 When I use v8.6.3 of GHC under Ubuntu to install the inline-r package
 I get the error "Type family equation violates injectivity annotation,"
 and
 a type variable on the LHS cannot be inferred from the RHS, due to
 the lack of injectivity (I suppose).

 On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under
 Ubuntu) does not have this problem (it has other problems).

 Has something changed in the latest version of the compiler that might
 cause this? Possible work-around?

 FYI, the line that triggers the error is:
 type instance G.Mutable (W t ty s) = Mutable.W t ty

 The variable that cannot be inferred is 's'.

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

>>> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
>