Cheng,
That's perfect. Thanks
On Thu, Jan 17, 2019, 11:51 PM Shao, Cheng Hi,
>
> I believe it's mentioned here:
>
>
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/RememberedSets
>
> Regards,
> Shao Cheng
>
> On Fri, Jan 18, 2019, 12:34 PM chessai . wrote:
>
>> Ryan,
>>
>> Tha
Hi,
I believe it's mentioned here:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/RememberedSets
Regards,
Shao Cheng
On Fri, Jan 18, 2019, 12:34 PM chessai . wrote:
> Ryan,
>
> That makes perfect sense, thanks. Is that documented explicitly anywhere?
> If not, I'd like to add
Ryan,
That makes perfect sense, thanks. Is that documented explicitly anywhere?
If not, I'd like to add the documentation to any place relevant.
Thanks
On Thu, Jan 17, 2019, 8:19 PM Ryan Yates Hi,
>
> Because GHC's GC is generational it needs a way to handle heap objects
> from older generation
Dear friends,
the other day I've run into an issue where I could not build a package. It
turned out that
the underlying reason was that the packages ghc ships with are not necessarily
the same
as they are on hackage. Ryan was kind enough to open Ticket 16199[1].
My use case is that I reduce th
Hi,
Because GHC's GC is generational it needs a way to handle heap objects from
older generations that point into younger generations. This only happens
when an older object is mutated to point to a younger object. GHC solves
this by invoking the GC write barrier (not to be confused with write
b
I feel as if I'm seeing the same commits many times. Is that right?
Simon
| -Original Message-
| From: ghc-tickets On Behalf Of GHC
| Sent: 17 January 2019 17:47
| Subject: Re: [GHC] #16105: Haddock's resource directory isn't properly
| handled by Hadrian
|
| #16105: Haddock's resource
Devs,
I've heard from a few friends that MutVars, TVars, etc. are more
challenging for the garbage collector. I'm writing to ask if someone can
answer: 1. Is this true, and 2: Why? I can't seem to find anything like a
writeup or documentation that mentions this. The HeapObjects trac page also
ment
Simon Peyton Jones via ghc-devs writes:
> I don't seem to be receiving notifications for my own MR:
> https://gitlab.haskell.org/ghc/ghc/merge_requests/128
> Richard and Ryan both commented, but I received literally no email about it.
> I'm set to "Watch" the GHC project.
Sigh, I thought I had f
I don't seem to be receiving notifications for my own MR:
https://gitlab.haskell.org/ghc/ghc/merge_requests/128
Richard and Ryan both commented, but I received literally no email about it.
I'm set to "Watch" the GHC project.
Any ideas?
Simon
PS: I am getting some notifications
* Thurs (today):
| Indeed this is a known issue that I have been working [1] with upstream
| to resolve.
Thanks. I'm not equipped to express a well-informed opinion about what the
best thing to do is. But in the meantime I WOULD be grateful for explicit
workflow advice. Specifically:
* What steps should I
Matthew Pickering writes:
> I am against any proposed change which makes it easier to break the
> build on any platform. Someone, usually Ben, has to waste a lot of
> time fixing these breakages and if master does not build it affects
> every developer.
>
Indeed, I agree with Matthew here. Breaka
Simon Peyton Jones via ghc-devs writes:
> Ben
>
> Six days ago I submitted this MR
> https://gitlab.haskell.org/ghc/ghc/merge_requests/109
> Just tiny refactorings. I said "merge when validated"
> But six days later, it still appears not to have merged. What's up? I
> was expecting it to merge i
I am against any proposed change which makes it easier to break the
build on any platform. Someone, usually Ben, has to waste a lot of
time fixing these breakages and if master does not build it affects
every developer.
If a commit breaks the build then it should prevent the patch being
merged. No
+1 on Simon's plan. I explicitly agree with the move not to validate before the
final commit (if a rebase is necessary); note that the successful rebase is
guaranteed not to have any conflicts (or else step 3 would have failed). We
should continue to do CI on the commits that have actually lande
To me it seems clear that GUARANTEEING that a patch won't break the master
branch is difficult; it serialises all patches, and it may require many
iterations.
Here's an obvious alternative for the "merge to master" pipeline;
1. Rebase the MR on master. If that fails, send email to the author.
15 matches
Mail list logo
