- User Since
- Jun 8 2014, 1:59 AM (154 w, 4 d)
Nice, I'll leave it for @simonpj to accept, just nits and style suggestions from me.
Tue, May 23
-pie seems reasonable to me. But couldn't -shared be used for this? There's an arguable consistency to it: -shared makes a dynamically-loadable library, it would be nice if it did the same thing for an executable.
Mon, May 22
Thu, May 18
Ok, passing back to you for refactoring. I'll take another look when you update the diff.
Wed, May 17
Ok, you're using a different test case now. It looks fine, but you didn't show the output of a type error message, which I think will demonstrate the problem.
Tue, May 16
Mon, May 15
We don't have a good way to virtualize the file system (or IO in general). My concern is that whatever mechanisms we put in place here won't be enough.
@simonmar, what do you think about this?
Nice observation about the unnecessary reloads, and the results look good. I presume with -O the unnecessary reloads will be eliminated by CmmSink, but eliminating them earlier saves compile time and helps with -O0.
If it works on Windows, go for it.
Thu, May 11
I think in your test case ApplicativeDo is not transforming the statement. You need to test it with an example that gets transformed after your diff.
I really don't like this, let's try to find alternative solutions.
Wed, May 10
To be clear I don't object to a stop-gap approach that allows BodyStmt to work with ApplicativeDo without going all the way to Trac #10892, but the first point in my previous comment still applies: I think this will break error messages. I'm not sure what the best way to fix this is so I'll let you experiment, but we have to retain the information somehow that the original statement was a BodyStmt so that it can be printed as such in an error message.
Tue, May 9
Ok, so there are a couple of problems with this approach
Mon, May 8
@kavon should have a look at this too
Fri, May 5
Well ok, if you can demonstrate a perf improvement then I won't object. GHC does use unsafeInterleaveIO, but as far as I know we've never identified it as a significant factor for performance (that could be because our profiling tools aren't good enough, of course). So my concerns are really around whether this is the most productive area to focus effort, rather than whether it's a good idea in isolation.
Thu, May 4
I think I benchmarked this when I was working on the backend and found that it was worse. What effect did it have on the perf tests?
Wed, May 3
@dfeuer what's this aiming at? Is there a problem with the old implementation, or are you trying to optimise it? If so, what's the benchmark?
Looks like it should be ok, although this is an unforced change so I feel slightly uneasy about it. Do we have good enough tests to be confident in this do you think?
Fri, Apr 28
Thu, Apr 27
I'm dubious too: there's no good way to test it, and we'll inevitably break it very quickly. Is there another way you could keep track of this file, perhaps in a separate github repo?
Wed, Apr 26
Oh wow, that's a good point. You should be able to change it to an unsafeDupableInterleaveIO if you also change the takeMVar to be readMVar.
Tue, Apr 25
Looks good to me. You could also clarify the docs a little by saying "i.e. it must be a pointer, but it doesn't matter if it's lifted or not"
Apr 25 2017
This is probably a lot more expensive than the MVar version. Recall that noDuplicate# walks the stack; it's an O(n) operation.
Apr 24 2017
fix test for Windows
Looks great, thanks for doing this!
Apr 22 2017
Wow, you folks are really dragging this code out of the 90s :)
Apr 20 2017
Yep, looks right to me. It won't be interruptible which is a shame, but at least that's not a regression. Thanks for doing this!
Apr 17 2017
I haven't done a complete review here, there's a lot I don't understand. Just a few questions below. My main concern is that we keep the elft/x86_64 parts of the linker working and don't introduce any perf regressions.
Just a few nits...
Ok when you've got clean builds on OS X and Windows.
Yes, it's time we removed this.
Apr 15 2017
Thanks for doing this!
Apr 13 2017
Apr 12 2017
Seems like there are two independent changes here, shouldn't they be separate diffs?
Mar 31 2017
Let's call that a separate problem, I don't think I've made it worse here. Arguably I've made it better because :set won't put you in an inconsistent state after you change your environment file.
Wow. I didn't do anything about point (1), I don't think this is the right place to take into account environment files, and I'm not sure what you mean by "obvious that we failed to pick up a package environment file because of the caching mechanism".
Make a data type for package DB flags
We should already have touch on Windows as part of the msys toolchain.
The test is maybe OS-specific, but I was optimistically hoping it might work on Windows. I don't have a Windows box to test on though. (can anyone help?)
Mar 30 2017
- packageFlagsChanged: check package DB flags too
- setLogAction: set log_finaliser too
Mar 29 2017
Accept test output
I think so.
Mar 28 2017
Mar 27 2017
Mar 20 2017
The right way to do this is to add new MachOps and implement them for all the native backends and LLVM. However, that's a lot of work and the Cmm versions are a reasonable second-best. (let's avoid the ByteArray# versions if we can)
Mar 17 2017
IdInfo is already lazy, BTW. Maybe this should just cover the ty and details.
Mar 16 2017
Mar 14 2017
We have the State# token yes, which enforces ordering of operations with respect to each other. So a read following a write will always occur in that order, as enforced by the state token passing.
We should probably have the test case from Trac #3207 in the test suite (I'm not sure why I didn't add it before)
Ugh. No, there's no centralized place that describes these things as far as I know.
Mar 13 2017
Currently, there's a mismatch between the note on has_side_effects, which says it should be False for read-only primops, and primops.txt.pp, which makes it True for these.
What's the rationale here? The commit log is a bit brief :)
I don't think I wrote this code, but my guess is that it has to do with proper handling of Ctrl-C. Can we still correctly interrupt compilation during the gcc phase without this?
Mar 9 2017
If I understand correctly this is saying that loading the .a is faster than loading the .so?
Mar 8 2017
It seems to be 80MB on disk, which comparing to an unpacked binary dist I have lying around (8.0.1) looks to be about 7%.
- Simplify; the way I was doing this was wrong
- Don't build a GHCi lib for the GHC package
Good point about the GHC package. The logic is here: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/ghc.mk;8e053700f9357c1b9030c406130062795ae5015c$603-611
Mar 6 2017
Ok, thanks for taking the time to explain the rationale for the design. I understand that things are evolving, my main concern is that we should be careful to capture the rationale in such a way that someone reading the code in the future can understand the constraints on the design - so preferably include Notes that explain why things are the way they are (in particular why we need to parse messages in the proxy), or use wiki pages with links from the code.