christiaanb (Christiaan Baaij)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 1 2014, 9:41 AM (210 w, 1 d)

Recent Activity

Sun, Nov 18

christiaanb created D5350: plugins10 no longer broken.
Sun, Nov 18, 7:26 AM
christiaanb updated the diff for D5348: Load plugins in interactive session.
  • Properly fix StaticPtr test fallout
Sun, Nov 18, 6:43 AM
christiaanb updated the diff for D5348: Load plugins in interactive session.
  • Fix StaticPtr testsuite fallout
Sun, Nov 18, 6:29 AM
christiaanb updated the diff for D5348: Load plugins in interactive session.
Sun, Nov 18, 6:11 AM

Sat, Nov 17

christiaanb created D5348: Load plugins in interactive session.
Sat, Nov 17, 7:44 AM

Oct 26 2018

christiaanb updated the diff for D5267: Comment out CONSTANT_FOLDED in GHC.Natural.

Fix testsuite output for now inlined negateNatural worker

Oct 26 2018, 10:38 AM
christiaanb created D5267: Comment out CONSTANT_FOLDED in GHC.Natural.
Oct 26 2018, 9:51 AM

Aug 10 2018

christiaanb updated the diff for D5048: Filter plugin dylib locations.
  • Correctly handle WayDyn in mkPluginUsage
Aug 10 2018, 10:50 AM
christiaanb updated the diff for D5048: Filter plugin dylib locations.
  • Correctly handle WayDyn in mkPluginUsage
Aug 10 2018, 2:26 AM

Aug 9 2018

christiaanb updated the diff for D5048: Filter plugin dylib locations.
  • Correctly handle WayDyn in mkPluginUsage
Aug 9 2018, 8:16 AM

Aug 8 2018

christiaanb added a comment to D5048: Filter plugin dylib locations.

Seems there’s another bug: https://ghc.haskell.org/trac/ghc/ticket/15492

Aug 8 2018, 3:13 PM

Aug 7 2018

christiaanb updated the diff for D5048: Filter plugin dylib locations.

Use filterM and add tests

Aug 7 2018, 6:44 AM

Aug 6 2018

christiaanb added a comment to D5048: Filter plugin dylib locations.

@monoidal I'll switch to just using filterM. w.r.t a test I'll see what I can do: I'd need to figure out how to either get A: two library search paths for a package, or B: get two libraries for one package.

Aug 6 2018, 1:19 PM
christiaanb created D5048: Filter plugin dylib locations.
Aug 6 2018, 9:50 AM

Jul 19 2018

christiaanb updated the diff for D4937: Plugin dependency information is stored separately.
  • Track object files of plugin in usages
Jul 19 2018, 6:23 AM

Jul 18 2018

christiaanb updated the diff for D4937: Plugin dependency information is stored separately.
  • Plugin dependency information is stored separately
  • Track object files of plugin in usages
Jul 18 2018, 10:55 AM

Jul 13 2018

christiaanb updated the diff for D4937: Plugin dependency information is stored separately.
  • Plugin dependency information is stored separately
  • Track object files of plugin in usages
Jul 13 2018, 8:48 AM

Jul 10 2018

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

@mpickering @bgamari This patch is ready for review now

Jul 10 2018, 1:46 PM
christiaanb updated the diff for D4937: Plugin dependency information is stored separately.
  • Track object files of plugin in usages
Jul 10 2018, 1:39 PM
christiaanb updated the diff for D4937: Plugin dependency information is stored separately.
  • Track object files of plugin in usages
Jul 10 2018, 3:31 AM

Jul 9 2018

christiaanb updated the diff for D4937: Plugin dependency information is stored separately.
  • Plugin dependency information is stored separately
  • Track object files of plugin in usages
Jul 9 2018, 12:51 PM

Jul 6 2018

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

Alright... I now understand how actually work checkDependencies: It checks whether all the current imported modules are equal to the imported modules from the last compilation run. If there's any difference, a recompile is triggered.
So what used to happen, before @mpickering's patch, is that plugin modules were never added to the field that stores the previously imported modules, and so plugins always triggered recompilation.
So after @mpickering patch, the plugins got added to the field that stores the previously imported modules, and so recompilation is no longer triggered automatically.
All my patch is currently doing is storing those plugins in a different field, which is only used by checkDependencies, and doesn't mess up the rest of GHC.

Jul 6 2018, 11:04 AM

Jul 5 2018

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

@mpickering No I didn't test it. But now on the offical ghc8.6rc1-alpha I'm having great difficulties triggering a recompilation of A.hs that uses the B.hs plugin by changing the source of B.hs when B is declared a pure plugin.

Jul 5 2018, 11:11 AM
christiaanb created D4937: Plugin dependency information is stored separately.
Jul 5 2018, 9:54 AM

Jan 4 2018

christiaanb created D4284: Export typeNat{Div;Mod;Log}TyCon from TcTypeNats.
Jan 4 2018, 10:24 AM

May 2 2017

christiaanb added inline comments to D3518: Add an Eq instance for UniqSet.
May 2 2017, 2:39 AM

May 1 2017

christiaanb added a comment to D3146: Upgrade UniqSet to a newtype.

This change removes the Eq instance for UniqSet: was this intentional? If so, why? If not, could this be added?

May 1 2017, 9:17 AM

Feb 9 2017

christiaanb updated the diff for D3105: zonkCt tries to maintain the canonical form of a Ct..
  • zonkCt tries to maintain the canonical form of a Ct.
Feb 9 2017, 11:30 AM
christiaanb updated the diff for D3105: zonkCt tries to maintain the canonical form of a Ct..
  • zonkCt tries to maintain the canonical form of a Ct.
Feb 9 2017, 11:08 AM

Feb 8 2017

christiaanb added inline comments to D3105: zonkCt tries to maintain the canonical form of a Ct..
Feb 8 2017, 4:05 PM
christiaanb retitled D3105: zonkCt tries to maintain the canonical form of a Ct. from Run canonicalize pass after type-checker plugins are done to zonkCt tries to maintain the canonical form of a Ct..
Feb 8 2017, 12:09 PM
christiaanb updated the diff for D3105: zonkCt tries to maintain the canonical form of a Ct..
  • Add a test for Trac #11525
  • zonkCt tries to maintain the canonical form of a Ct.
Feb 8 2017, 12:06 PM
christiaanb added a comment to D3105: zonkCt tries to maintain the canonical form of a Ct..

Sound OK?

Feb 8 2017, 9:31 AM
christiaanb added a comment to D3105: zonkCt tries to maintain the canonical form of a Ct..

It seems that

Feb 8 2017, 7:58 AM
christiaanb added a comment to D3105: zonkCt tries to maintain the canonical form of a Ct..

I'd much prefer to follow comment:7 on Trac Trac #11525. Was there some reason you chose not to do that?

Feb 8 2017, 6:41 AM
christiaanb updated the diff for D3105: zonkCt tries to maintain the canonical form of a Ct..
  • Fix T11525 test case
Feb 8 2017, 4:19 AM
christiaanb updated the summary of D3105: zonkCt tries to maintain the canonical form of a Ct..
Feb 8 2017, 3:59 AM
christiaanb created D3105: zonkCt tries to maintain the canonical form of a Ct..
Feb 8 2017, 3:43 AM

Feb 3 2017

christiaanb added a comment to D3024: Introduce GHC.TypeNats module, change KnownNat evidence to be Natural.

I think I agree with @christiaanb about this. What is the benefit of adding natural literals to core? Trac #13186 provides no motivation and this patch provides no motivation for changing the non-core representation to be Natural. It seems much easier to keep the internal representation as Integer and convert it once to a natural in a library somewhere if that is the evidence you want to provide.

I think there is an argument that can be made either way here. I'm personally rather agnostic on the question and would have been happy to continue using an Integer representation but I can see why @dfeuer would object that we should be more precise in our types. I think David would say that the fact that Nat was backed by an Integer should be viewed as a historical mistake and we should be writing the code that we want, not the code that we happened to stumble our way into.

Feb 3 2017, 10:09 AM
christiaanb added a comment to D3024: Introduce GHC.TypeNats module, change KnownNat evidence to be Natural.

Seeing this is already merged, I guess I'm too late to object to the current implementation. Anyhow, my question is, why is this implementation chosen instead of either:

Feb 3 2017, 3:36 AM

Oct 18 2016

christiaanb accepted D2611: Add and use a new dynamic-librariy-dirs field in the ghc-pkg info.
Oct 18 2016, 1:25 PM

Jan 4 2016

christiaanb added a comment to D1727: DynFlags: remove noop '-fmax-worker-args' flag.

I (sadly) don't see myself working on reinstating -fmax-worker-args. However, given that it was unintentionally rendered a no-op during improvement of the demand analysis phase, I would think removing it entirely is a mistake. Instead, I think it would be better if GHC issued a warning that -fmax-worker-args is currently a no-op.

Jan 4 2016, 2:05 AM

Oct 27 2015

christiaanb updated the diff for D1372: Make worker-wrapper optional.
  • -fno-strictness implies -fno-worker-wrapper
Oct 27 2015, 4:33 AM

Oct 26 2015

christiaanb updated the diff for D1372: Make worker-wrapper optional.
  • -fstrictness implies -fworker-wrapper
Oct 26 2015, 11:27 AM
christiaanb added a comment to D1372: Make worker-wrapper optional.

I'm OK with -fstrictness implying -fworker-wrapper. However, it would be an exception to the (currently implemented) rule, when -O -fno-strictness would then also imply -fno-worker-wrapper. See also: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/main/DynFlags.hs#l3601

Oct 26 2015, 11:27 AM
christiaanb retitled D1372: Make worker-wrapper optional from to Make worker-wrapper optional.
Oct 26 2015, 11:27 AM

Aug 1 2015

christiaanb updated D1115: Add framework flags when linking a dynamic library.
Aug 1 2015, 2:14 PM
christiaanb updated the diff for D1115: Add framework flags when linking a dynamic library.
  • Remove copy-paste error
Aug 1 2015, 2:03 PM
christiaanb added a comment to D1115: Add framework flags when linking a dynamic library.

@christiaanb, might it also make sense to handle Cabal issue 2689 (ensuring framework headers are in the include path) here as well? Or will this be taken care of for us by -framework?

Aug 1 2015, 4:39 AM
christiaanb updated the diff for D1115: Add framework flags when linking a dynamic library.
  • Refactor get(Pkg)FrameworkOpts
Aug 1 2015, 4:35 AM

Jul 31 2015

christiaanb updated the diff for D1110: Make -fcpr-off a dynamic flag.
  • Replace negative -fcpr-off by positive -fcpr-anal
Jul 31 2015, 6:59 AM
christiaanb added a comment to D1110: Make -fcpr-off a dynamic flag.

That's good, thanks. But let's make it a positive flag, like -fstrictness (on by default in -O, -O2). Maybe -fcpr-anal?

Jul 31 2015, 6:15 AM
christiaanb retitled D1115: Add framework flags when linking a dynamic library from to Add framework flags when linking a dynamic library.
Jul 31 2015, 5:00 AM
christiaanb updated the diff for D1110: Make -fcpr-off a dynamic flag.

Rebase against latest master so that harbormaster will hopefully build

Jul 31 2015, 4:34 AM

Jul 30 2015

christiaanb updated the diff for D1110: Make -fcpr-off a dynamic flag.
  • Revert "Make -fcpr-off a dynamic flag"
  • Second try: Make -fcpr-off a dynamic flag
Jul 30 2015, 4:33 AM
christiaanb updated D1110: Make -fcpr-off a dynamic flag.
Jul 30 2015, 4:32 AM

Jul 29 2015

christiaanb added a comment to D1110: Make -fcpr-off a dynamic flag.

Not much thought was given to how -fcpr-off works.

Currently its works by not *generating* CPR info.

But an alternative would be not to *exploit* CPR info, specifically during worker/wrapper generation. The advantage is that this is done in ONE place, namely mkWWcpr, in WwLib. That in turn is called only from mkWwBodies which already gets DynFlags. Easy!

So that would mean that CPR analysis still happens, but GHC generates no w/w split.

I think this would be a better plan. OK?

Jul 29 2015, 11:34 AM
christiaanb updated D1110: Make -fcpr-off a dynamic flag.
Jul 29 2015, 10:44 AM
christiaanb updated D1110: Make -fcpr-off a dynamic flag.
Jul 29 2015, 7:41 AM
christiaanb retitled D1110: Make -fcpr-off a dynamic flag from to Make -fcpr-off a dynamic flag.
Jul 29 2015, 7:32 AM

May 28 2015

christiaanb accepted D909: Add constraint creation functions to TcPluginM API.
May 28 2015, 2:24 AM
christiaanb added a comment to D909: Add constraint creation functions to TcPluginM API.

Yes, I'm happy that there a both the simple wrappers to create constraints, and a way to manipulate the EvBindsVar directly.

May 28 2015, 2:20 AM

Apr 27 2015

christiaanb retitled D870: Normalise type families in the type of an expression from to Normalise type families in the type of an expression.
Apr 27 2015, 5:20 AM

Dec 1 2014

christiaanb accepted D545: Fix malformed `configure` script.

This makes ./configure go through on my machine now, where it didn't before this patch.

Dec 1 2014, 9:52 AM