- User Since
- Jun 5 2014, 10:16 AM (224 w, 3 d)
Thu, Sep 20
hadrian doesn't need this patch anymore indeed, and I believe this was the only motivation for this patch -- can you confirm @hsyl20?
Great! I believe this would have helped me during my investigation from Trac #15570.
Wed, Sep 12
I can confirm that T8242 passes now, with the accompanying hadrian PR (here):
I have a build running, and it'll run the test at the end. I'll report back once it's all over.
Tue, Sep 11
Looks like that didn't break anything for the make build system either, judging from the harbormaster builds.
Mon, Sep 10
@simonmar I implemented both of your suggestions. Thanks!
- remove findPtr hack in rts/package.conf.in, give an helpful error message when not running a debugged RTS
- silence unused argument warning/error
Fri, Sep 7
- address unused parameter error
Tue, Sep 4
Fri, Aug 31
Mon, Aug 27
Only T3171 left to fix (https://circleci.com/gh/ghc/ghc-diffs/270)
- bigger multiplier for MultiLayerModules
And here's the ticket with the self-contaiend reproducer: https://ghc.haskell.org/trac/ghc/ticket/15570#ticket
I made some more tweaks and triggered a new Circle CI build for i386: https://phabricator.haskell.org/harbormaster/build/52342/
- tweak timeout multipliers for bkpcabal01 and T13701(again)
Aug 24 2018
https://circleci.com/gh/ghc/ghc-diffs/256#build-parameters/containers/0: MultiLayerModules passed but another one is failing, and T13701 is still not passing.
We'll eventually get the CircleCI build log url and more.
Aug 22 2018
That was my suspicion, thanks for clarifying!
Out of curiosity, if this is a _performance_ optimisation, do we have any numbers we can leave here for posterity?
The patch looks good, but Note [String unpack closures are non-updateable] has yet to be written.
The only CI failures are on OS X and they're stats failures. I'm no typechecker expert but the feedback got addressed and the test included with this patch is indeed passing. Any objection to merging this fix?
Aug 4 2018
Aug 2 2018
Can you checkout 2a3175f886b86697194256f55c9487b7cfb4dc92 in libraries/Cabal/, make sure you don't have dirty files in that sub-directory, and then from the top of the GHC source tree git add libraries/Cabal && git commit ... && arc diff ?
It should be enough to checkout whatever commits master points to for those two submodules, git add libraries/Cabal libraries/terminfo and then git commit -m ... and arc diff.
Aug 1 2018
Done in another commit.
Jul 31 2018
Jul 30 2018
LGTM. Yeah -fobject-code seems to be a better default. Just make sur you document the most efficient/handy (but more complicated) workflow somewhere visible like one of the "building ghc" pages on trac eventually, so that people can pick it up.
Jul 27 2018
- Merge branch 'master' into wip/alp/14483-getexecutablepath-windows
Jul 26 2018
I didn't get around to figuring out the source of the Windows CI troubles. I can put this patch back on my radar and look into this in the upcoming days.
Jul 25 2018
testsuite/tests/ghci/ would be a good place I suppose.
And CI will indeed tell us whether a full make succeeds.
One last typo and we're good. OK for the Prelude imports, I see the reasoning.
Looks great, except for the typos in the extension's name =)
Jul 24 2018
Alright, since there aren't any particularly obvious recommendations to give for the other two, I stand corrected and accept this patch as-is.
This looks good to me. I'd love to have something that makes sure this is not broken (a test that just runs your script?), but I don't think we necessarily want to hold this patch on that.
Maybe I'm not seeing it because I'm tired, but how come you needed to add all those NoImplicitPreludes and import Preludes ?
Just a minor request, but otherwise looks good to me and will be very handy (if anything, our plots will look nice & balanced).
Jul 20 2018
That bothered me as well in the past. Thanks!
Jul 10 2018
Jul 9 2018
Would we perhaps want the ghci scripts to live somewhere else than at the top level (say a scripts/ directory) ?
Jul 6 2018
Did you test this causes recompilation when the plugin module changes?
Jul 5 2018
Don't we want to expect this test to be broken? This is otherwise makig CI fail.
Jul 4 2018
I was confused initially by the fact that the revision title talks about adding foldMap' while in fact this changes an existing implementation. LGTM.
Just one tiny request, to get rid of a warning we can easily avoid. Other than that, looks good to me.
Jun 28 2018
It looks like switching to the ghc-diffs repo you created as a "staging" one for the Circle CI builds did the trick. Not sure how important the core detection logic was in making this work, but I suppose it is anyway better not to just blindly run with -j9.
Jun 27 2018
The build got killed: https://circleci.com/gh/alpmestan/ghc/15
Jun 26 2018
I triggered a build against my circle ci integration, through phab's build step interface. Let's see how it goes: https://circleci.com/gh/alpmestan/ghc/15 (previously, it'd just blow up, trying to build and run things with -j9 on a 2 core box with 4GB of RAM).
Jun 16 2018
Thanks! This was quite annoying when I implemented a nofib rule in hadrian.
Jun 3 2018
This is great. Hiding the whole symbol table / dictionary business from the user when he/she does not have to care about it certainly is an improvement from my point of view and I in fact could use this patch right now for a branch I'm working on.
May 25 2018
May 23 2018
May 20 2018
May 14 2018
The reason that validate --slow might not be exactly the same as what we see in CI is that validate --slow enables DEBUG for stage 2, whereas we don't do that in CI because we're building binaries for distribution and DEBUG would make them slower. The warning messages you're seeing in the Cabal tests are only emitted when the compiler is built with DEBUG. (apologies if this was pointed out elsewhere, I haven't read all the surrounding tickets here)
May 11 2018
OK, let's see what CI says with D4686. I will also run ./validate --fast in a Windows VM. I'm just using "changes requested" as an "on hold" tag.
I ended up writing a similar patch (that adds a field to Settings, to keep things pure), before stumbling on the phab notification for this diff (sorry). I don't mind this use of unsafePerformIO, even though I tend to prefer code that doesn't use it. This should regardless definitely fix the problem.
Apr 18 2018
Apr 17 2018
Apr 16 2018
Yes, I can. I guess I can turn my attention to this as soon as I'm done with the unexpected failures I'm seeing when running ./validate --slow. We'll still have the stats failures left to handle.
Apr 11 2018
Thanks! This will fix the failures I'm seeing.
Mar 31 2018
Mar 27 2018
Quite intriguing. So, as Simon suggests in Trac #14965, this indeed got fixed between 8.4.1 and 8.4.2? (judging from the green CI here)
Mar 21 2018
Looks good to me. I restarted the windows build as it was failing with what looks like a transient error:
LGTM. This test _is_ executed by harbormaster right?
Mar 2 2018
Looks good. This should be a drastical improvement for situations like the one described in #12706.
Feb 28 2018
More details on why Herbert's fix is necessary in the ticket.
Feb 27 2018
hvr found that it's enough to build & run the following trivial program with stage 1:
Feb 25 2018
Just for the record, this has been discussed on the libraries@ mailing list here. The patch looks good to me.
Feb 14 2018
Hmm, CI is now failing because of:
Feb 13 2018
For the record, I was bitten by a parse error in utils/hp2ps/hp2ps.cabal when building with hadrian a little earlier and this patch fixed it.
Jan 30 2018
I think I'll be able to do without the need to ship this with ghc, which is in my opinion much, much better.
Sorry for the lack of reactivity on this diff, I somehow didn't get the notifications for all the comments.