- User Since
- Jan 8 2015, 11:07 PM (123 w, 6 d)
Thank you for the detailed explanation. But I'm not clearer than before on my second question: why are the file/process opesrtions you just added not subject to the same issues that qRunIO has? After all, they're also IO operations. Where specifically in the GHC codebase does a cross compiler make the decision to, e.g., look up executables on the build machine instead of the host machine when running qFindExecutables?
My apologies for not being familiar with the previous work on this front, but I don't see why this is necessary. Why does adding a bunch of hardcoded IO operations to Quasi resolve this issue, but qRunIO alone does not? Where in the code are cross compilers making the distinction between files on the build machine and files on the host machine when running, e.g., qFindExecutables?
Sun, May 14
- Include test output
Fri, May 12
Thu, May 11
Sat, May 6
Thu, May 4
Wed, May 3
Thu, Apr 27
- Remove errant runIO
Wed, Apr 26
Tue, Apr 25
Thanks for doing this, @adamse! I've left some inline remarks.
- Accept new test output
We should add the program in Trac #13609 as a test case, no?
Apr 24 2017
Oops, grabbed too many commits
Rebase (and cross fingers for a green Harbormaster build)
Apr 23 2017
ghci063 (as currently written) does not pass on Windows. Here is the error that I get:
Apr 20 2017
- simonpj's suggestions
Apr 19 2017
Apr 6 2017
Apr 4 2017
That was some quite impressive turnaround time.
Ought the title of this Diff be "Mark unfold as deprecated"?
We definitely need to point out this change in libraries/base/changelog.md. Note that the deadline for base-184.108.40.206 (which will be shipped with GHC 8.2 soon) has already passed, so this would be incorporated into the base-220.127.116.11 release. At the moment, however, libraries/base/changelog.md doesn't have a section for base-18.104.22.168—do you mind making this change yourself? Just put a new section at the top like:
Apr 1 2017
Looks good overall. Make sure to mention this in the 8.4 release notes!
Mar 31 2017
Mar 30 2017
It's not terribly clear to me how this works. This needs
Fantastic work, @dfeuer!
Mar 29 2017
Mar 25 2017
Mar 24 2017
One thing I'm not clear on is how the fixity of record pattern synonym field operators work. Is there a default fixity? Can it be configured? Is whatever the current behavior is documented in the users' guide?
Mar 23 2017
Ah, I see. It's because mk_FunBind (which Eq and Ord use) had its behavior changed by modifying mkRdrFunBind. I'm fine with either leaving things the way they are for Eq/Ord, or changing it to generate the "correct" number of wildcard patterns. If you do opt for the latter route, make sure that other classes behave properly as well! For instance, Data, Lift, and Show, which also use mk_FunBind.
Mar 22 2017
Mar 16 2017
Mar 15 2017
Mar 14 2017
Mar 13 2017
Mar 12 2017
- Point Haddock submodule to my fork
Note: this requires a change to haddock. Currently, it's only available at https://github.com/RyanGlScott/haddock/commit/661d33cae917ab4dca9e4a87e56542769b0fa109 (my GitHub fork of haddock), since I don't know how to push these changes to git.haskell.org/haddock.git itself.
Mar 11 2017
By the way, this change was motivated by the fact that if you currently import typeRepFingerprint from Data.Typeable and try using it on a TypeRep, it'll fail with a type error, since you're not using the type-indexed variant from Type.Reflection. So this is equally a bugfix and a code cleanup.
A quick Google search reveals this: https://mail.haskell.org/pipermail/libraries/2015-July/026039.html
Has this proposed change been discussed on the libraries mailing list? I'm quite reluctant to add new instances to base without some semblance of community consensus that they should go in.
Mar 10 2017
I feel like I need some more context here. Is there a reason you're targeting these four types in particular? What is the intended use case for these functions?
@bgamari indicated that we might want to hold off on this for another release cycle, since these were only deprecated very recently (GHC 8.0). Bumping out of the accepted state for now.
Cool! One minor comment inline.
- Simon's suggestions
Mar 9 2017
- Richard's suggestions
Looks good. Make sure to include a note in the changelog. (Currently, the notes for the 2.11 release claim that FamFlavour was removed, which technically isn't true... maybe we should fix that retroactively? :) )
BTW, the tweaks I made to various files in the testsuite are just reverting changes that Simon made in 8136a5cbfcd24647f897a2fae9fcbda0b1624035 to make them compile under the associated types restriction that this commit reverts.
Mar 7 2017
OK. Can you put a blurb in the base changelog stating that these functions have been removed? In practice, I have encountered a Hackage library (dynamic-state) that uses them, so we should have a migration story.
What about tyConFingerprint? mkTyCon3? mkTyConApp? mkAppTy? mkFunTy?
@Phyx, I'm confused about what issue(s) this is fixing. You marked the Trac issue on this Diff as Trac #13384, but didn't change the Differential status on the corresponding Trac page. Moreover, you did change the Differential on the Trac page for Trac #13359, but you didn't mark this Diff as fixing it. Does it fix both? Or just one of them?