Thanks Simon, this is really helpful.
> If you look at scavenge_fun_srt() and co, you'll see that they return
> immediately if !major_gc.
Thanks for pointing this out -- I didn't realize it's returning early when
!major_gc and this caused a lot of confusion. Now everything makes sense.
I'll add
On Tue, May 1, 2018 at 9:58 PM, Ben Gamari wrote:
> Yes, I suppose the language in the release notes does rather understate
> the degree of the incorrectness.
>
> I'll push a new version of the manual with some stronger language
> tomorrow.
Good deal, thanks for the quick response.
__
Evan Laforge writes:
> I recently noticed that with -O1, ghc was optimizing some code
>
> if Trace.traceShowId "b" $ True
> then return $ Left $ Serialize.BadMagic (Serialize.magicBytes
> magic) file_magic
> else first Serialize.UnserializeError <$> Exception.evaluate
> (Seria
I recently noticed that with -O1, ghc was optimizing some code
if Trace.traceShowId "b" $ True
then return $ Left $ Serialize.BadMagic (Serialize.magicBytes
magic) file_magic
else first Serialize.UnserializeError <$> Exception.evaluate
(Serialize.decode rest)
to always evaluat
I'm afraid I don't know a quick answer to that one. Does anyone else? If no one
answers, write back in a few days and I'll look into it.
Richard
> On May 1, 2018, at 3:09 AM, alice wrote:
>
> Thanks a lot, this helped!
>
> But sorry for asking, before this problem I evaluated Cmp on some valu
Fixed!
Am Dienstag, den 01.05.2018, 15:48 -0400 schrieb David Feuer:
> The ghc-proposals repository does not have the issue tracker enabled, so it's
> currently impossible to open an issue.
>
> On Tuesday, May 1, 2018 3:31:24 PM EDT Joachim Breitner wrote:
> > Hi,
> >
> > the distiction between
The ghc-proposals repository does not have the issue tracker enabled, so it's
currently impossible to open an issue.
On Tuesday, May 1, 2018 3:31:24 PM EDT Joachim Breitner wrote:
> Hi,
>
> the distiction between an issue and a pull request is a rather thin
> one, and the Github API actually all
I suppose that would be a reasonable alternative. But to keep discussion
tracking reasonable, I suspect it would be best to close the pre-proposal
PR and open a new one (with mutual links) for the actual proposal if and
when the time comes.
On Tue, May 1, 2018, 3:24 PM Richard Eisenberg wrote:
>
Hi,
the distiction between an issue and a pull request is a rather thin
one, and the Github API actually allows you to upgrade an issue to a
pull request…
So no need to be picky about the precise form: If someone has something
interesting to say in an issue without yet having some text to attach
I like this idea, but I think this can be done as a PR, which seems a better
fit for collaborative building. The author can specify that a proposal is a
"pre-proposal", with the goal of fleshing it out before committee submission.
If it becomes necessary, we can furnish a tag to label these, but
Your explanation is basically right. scavenge_one() is only used for a
non-major collection, where we aren't traversing SRTs. Admittedly this is a
subtle point that could almost certainly be documented better, I probably
just overlooked it.
More inline:
On 1 May 2018 at 10:26, Ömer Sinan Ağacan
Sometimes, a language extension idea could benefit from some community
discussion before it's ready for a formal proposal. I'd like to propose
that we open up the GitHub issues tracker for ghc-proposals to serve as a
place to discuss pre-proposal ideas. Once those discussions converge on one
or a f
Friends
I'm seeing test-suite wobbles like these:
Unexpected failures:
/tmp/ghctest-9ez8i8lx/test spaces/./ghci.debugger/scripts/break006.run
break006 [bad stdout] (ghci)
/tmp/ghctest-9ez8i8lx/test spaces/./ghci.debugger/scripts/hist001.run
hist001 [bad stdout] (ghci)
/tmp/ghc
I have an idea but it doesn't explain everything;
SRTs are used to collect CAFs, and CAFs are always added to the oldest
generation's mut_list when allocated [1].
When we're scavenging a mut_list we know we're not doing a major GC, and
because mut_list of oldest generation has all the newly alloc
Thanks a lot, this helped!
But sorry for asking, before this problem I evaluated Cmp on some values with *
kinds, and I used (mkTemplateAnonTyConBinders [ liftedTypeKind, liftedTypeKind
]) to make the input kinds for TyCon.
Changing function to mkTemplateTyConBinders (right now this part looks l
15 matches
Mail list logo