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
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
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,
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
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 Ma
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
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-do
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,
>>
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 t
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 "Tog
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
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" actua
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 c
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
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
| 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 comm
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 Discus
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 Eisenb
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
"di
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
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
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 catche
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
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 v
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.h
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
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
> hackag
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
co
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
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
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 b
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.
Be
32 matches
Mail list logo
