# Projects

User does not belong to any projects.

# User Details

User Since
Jun 5 2014, 10:16 AM (214 w, 6 d)
Roles

Looks good.

# Mon, Jul 9

Would we perhaps want the ghci scripts to live somewhere else than at the top level (say a scripts/ directory) ?

# Fri, Jul 6

alpmestan added a comment to D4937: Plugin dependency information is stored separately.

Did you test this causes recompilation when the plugin module changes?

# Thu, Jul 5

alpmestan requested changes to D4921: testsuite: Add test for #12449.

Don't we want to expect this test to be broken? This is otherwise makig CI fail.

# Wed, Jul 4

I was confused initially by the fact that the revision title talks about adding foldMap' while in fact this changes an existing implementation. LGTM.

alpmestan requested changes to D4927: Export findImportUsage and ImportDeclUsage.

Just one tiny request, to get rid of a warning we can easily avoid. Other than that, looks good to me.

# Thu, Jun 28

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.

# Wed, Jun 27

alpmestan added a comment to D4897: circleci: Detect core count.

The build got killed: https://circleci.com/gh/alpmestan/ghc/15

# Tue, Jun 26

alpmestan added a comment to D4897: circleci: Detect core count.

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 14 2018

alpmestan added a comment to D4636: Fix another batch of ./validate --slow failures.

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

alpmestan requested review of D4636: Fix another batch of ./validate --slow failures.
alpmestan requested changes to D4667: Fix testsuite runs by expanding tooldir.

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 16 2018

alpmestan added a comment to D4354: CircleCI: Run nightly validate --slow.

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.

alpmestan added inline comments to D4546: tweak many test expectations, towards a green ./validate --slow.

# 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

alpmestan added a comment to D4459: GHCi info: Use src file for cache invalidation.

Looks good. This should be a drastical improvement for situations like the one described in #12706.

# Feb 28 2018

alpmestan added a comment to D4453: 8.4: bump cabal to 2.2 (with ghc-cabal).

More details on why Herbert's fix is necessary in the ticket.

# Feb 27 2018

alpmestan added a comment to D4453: 8.4: bump cabal to 2.2 (with ghc-cabal).

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

alpmestan added a comment to D4403: Make accumArray and accum stricter.

Hmm, CI is now failing because of:

# Feb 13 2018

alpmestan added a comment to D4406: Update .cabal files for Cabal 2.1.

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.

# Jan 16 2018

alpmestan updated the summary of D4317: tentative improvement to callstack docs.

# Dec 6 2017

alpmestan added inline comments to D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.

# Dec 5 2017

alpmestan added inline comments to D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.

We could however also just add the Makefile from this diff to master, and just use it in our hadrian branch to complete the binary dist work. But at least we can discuss it.

The hadrian commit will have to be changed once https://github.com/angerman/hadrian/pull/1 is merged. This was meant as a diff against Moritz's branch though, not sure that's what happened.

# Dec 1 2017

alpmestan updated the diff for D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.
• conditionals for redundant import warning
alpmestan updated the diff for D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.
• redundant imports

# Nov 30 2017

alpmestan updated the diff for D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.
• fix the windows, base >= 4.11 implementation of getBaseDir
alpmestan updated the diff for D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.
• SysTools.BaseDir: import getExecutablePath on Windows too, fix rootDir typo

# Nov 29 2017

I've addressed the feedback and rebased on top of master. Let's see if harbomaster is happy with that.

alpmestan updated the diff for D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.
• factor out 'rootDir'
• simplify rootDir
• import getExecutable on Windows too, when when can use it
• fix redundant imports
• rebase on top of master
alpmestan updated the diff for D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.
• fix redundant imports
alpmestan updated the diff for D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.
• simplify rootDir
• import getExecutablePath on Windows too

# Nov 24 2017

alpmestan added inline comments to D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.

alpmestan updated the diff for D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.

Added a changelog entry for base.

# Nov 23 2017

alpmestan updated the diff for D4229: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0.
• factor out 'rootDir'
• document the new behaviour of 'getExecutablePath' on Windows