dfeuer (David Feuer)Administrator
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 5 2014, 5:38 PM (222 w, 4 d)
Roles
Administrator

Recent Activity

Thu, Dec 6

dfeuer added inline comments to D4777: Implement the Unlifted Newtypes proposal. This is proposal 13 on the ghc-proposals repo and is fully described there..
Thu, Dec 6, 10:21 PM

Wed, Dec 5

dfeuer added inline comments to D4777: Implement the Unlifted Newtypes proposal. This is proposal 13 on the ghc-proposals repo and is fully described there..
Wed, Dec 5, 10:19 PM
dfeuer added a comment to D4777: Implement the Unlifted Newtypes proposal. This is proposal 13 on the ghc-proposals repo and is fully described there..

You seem to have accidentally reverted everything.

Wed, Dec 5, 8:23 PM

Tue, Nov 13

dfeuer added a comment to D5313: Make `UniqDSet` a newtype.

Thanks for taking care of this!

Tue, Nov 13, 9:08 AM
dfeuer added a comment to D5315: More compact Outputable instance for `Uniq(D)Set`.
In D5315#146815, @sgraf wrote:

Of course. I realised that we ''might'' want to consider sticking to brackets instead of braces, but on the other hand this would severely clash with how lists are formatted.

Tue, Nov 13, 9:07 AM

Oct 9 2018

dfeuer added a comment to D4475: RFC: Add Int8# and Word8#.

We still support i386? Intel stopped manufacturing those in 2007, and
many/most/all embedded system manufacturers stopped using them once stocks
ran out. I believe the same is true of the 486.

Oct 9 2018, 12:18 PM

Oct 8 2018

dfeuer added inline comments to D5201: Fix dataToTag# argument evaluation.
Oct 8 2018, 10:51 AM

Oct 5 2018

dfeuer added a comment to D5201: Fix dataToTag# argument evaluation.

The small type optimization is low priority. I realized we never use dataToTag# for small types in Ord deriving anyway!

Oct 5 2018, 2:09 AM

Oct 4 2018

dfeuer added inline comments to D5201: Fix dataToTag# argument evaluation.
Oct 4 2018, 3:16 AM
dfeuer added inline comments to D5201: Fix dataToTag# argument evaluation.
Oct 4 2018, 3:11 AM

Sep 17 2018

dfeuer updated the diff for D5155: Completely rework stable names.
  • Continue
Sep 17 2018, 8:20 PM
dfeuer updated the diff for D5155: Completely rework stable names.
  • Continue
Sep 17 2018, 8:18 PM
dfeuer added inline comments to D5155: Completely rework stable names.
Sep 17 2018, 6:44 PM
dfeuer updated the diff for D5155: Completely rework stable names.

Typo

Sep 17 2018, 6:44 PM
dfeuer created D5155: Completely rework stable names.
Sep 17 2018, 6:43 PM

Sep 14 2018

dfeuer updated the diff for D5152: Stable name comment wibbles.
  • Skip CI
Sep 14 2018, 5:25 PM
dfeuer added a comment to D5117: Stable name type role.

@simonmar, I reverted all that fancy machinery that turned out to be rather silly. I also split this into two commits: one for the type role change and one for the comment wibbles. Could I get another accept mark?

Sep 14 2018, 5:22 PM
dfeuer created D5152: Stable name comment wibbles.
Sep 14 2018, 5:21 PM
dfeuer retitled D5117: Stable name type role from Stable name comments and type role to Stable name type role.
Sep 14 2018, 5:20 PM
dfeuer updated the diff for D5117: Stable name type role.
  • Split differential; rebase; revert silliness
Sep 14 2018, 5:20 PM
dfeuer added inline comments to D5117: Stable name type role.
Sep 14 2018, 11:44 AM
dfeuer added inline comments to D5117: Stable name type role.
Sep 14 2018, 7:47 AM

Sep 10 2018

dfeuer requested review of D5117: Stable name type role.

I had to make some changes. Could someone please have another look?

Sep 10 2018, 4:58 AM

Sep 9 2018

dfeuer updated the diff for D5117: Stable name type role.
  • Hopefully this is the last
Sep 9 2018, 11:53 PM
dfeuer updated the diff for D5117: Stable name type role.
  • Silly me
Sep 9 2018, 7:02 PM
dfeuer updated the diff for D5117: Stable name type role.
  • Typo
Sep 9 2018, 6:31 PM
dfeuer updated the diff for D5117: Stable name type role.
  • Don't go quite so far
Sep 9 2018, 5:26 PM
dfeuer updated the diff for D5117: Stable name type role.
  • Don't go quite so far
Sep 9 2018, 4:04 PM
dfeuer planned changes to D5117: Stable name type role.

The StableName type in base needs to go back to having a representational parameter. The stable-maps package relies on that for safety.

Sep 9 2018, 2:57 PM

Aug 30 2018

Herald added a reviewer for D5117: Stable name type role: bgamari.
Aug 30 2018, 2:24 PM

Aug 29 2018

dfeuer committed rGHCf48e276a5ba6: Finish stable split (authored by dfeuer).
Finish stable split
Aug 29 2018, 3:35 PM
dfeuer closed D5084: Finish stable split.
Aug 29 2018, 3:35 PM
dfeuer updated the diff for D5084: Finish stable split.

Rebase

Aug 29 2018, 3:25 PM
dfeuer updated the diff for D5084: Finish stable split.
  • Update release notes
Aug 29 2018, 3:17 PM
dfeuer updated the summary of D5084: Finish stable split.
Aug 29 2018, 3:08 PM
dfeuer updated the diff for D5084: Finish stable split.
  • Formatting wibble
Aug 29 2018, 11:00 AM
dfeuer updated the summary of D5084: Finish stable split.
Aug 29 2018, 11:00 AM
dfeuer updated the diff for D5084: Finish stable split.
  • Silly syntax error
Aug 29 2018, 11:00 AM
dfeuer updated the diff for D5084: Finish stable split.
  • Don't bother trying to deprecate the C stuff. It seems tricky.
Aug 29 2018, 10:15 AM

Aug 28 2018

dfeuer updated the diff for D5084: Finish stable split.
  • Remove outdated comment
Aug 28 2018, 4:18 PM
dfeuer added a comment to D5084: Finish stable split.

@simonmar, based on @bgamari's understanding and my own, I've removed the code to lock and unlock the stable name table during GC. If that's wrong, let me know. I've also updated the FFI names and added deprecation attributes for gcc and clang. Is there anything more to do here, or can we get this little business over with?

Aug 28 2018, 4:18 PM
dfeuer updated the diff for D5084: Finish stable split.
  • More cleanup
Aug 28 2018, 4:18 PM
dfeuer added a comment to D5084: Finish stable split.

Also, it appears that GCC, clang, and at least some other C compilers support a __deprecated__ attribute that we should be able to use. Should I just boldly use it, or should I try to use CPP somehow to check if the compiler supports it?

Aug 28 2018, 1:22 PM
dfeuer added a comment to D5084: Finish stable split.

@simonmar, I'll get those FFI names sorted. My remaining question is whether we need to lock the stable name table for GC, or only the stable pointer table. The code doesn't explain why the garbage collector locked the stable tables. Is that because there could be C code hoping to free stable pointers while GC is in progress, or is there another reason?

Aug 28 2018, 1:16 PM

Aug 27 2018

dfeuer updated the diff for D5084: Finish stable split.
  • Document unsafe stable pointer operations
Aug 27 2018, 7:38 PM
dfeuer added inline comments to D5084: Finish stable split.
Aug 27 2018, 4:46 PM
dfeuer updated the diff for D5084: Finish stable split.
  • Document unsafe stable pointer operations
Aug 27 2018, 3:44 PM
dfeuer updated the diff for D5084: Finish stable split.

Rebase

Aug 27 2018, 3:02 PM
dfeuer abandoned D5081: Use pointer equality to compare StableNames.

I've folded this into D5084.

Aug 27 2018, 3:02 PM
dfeuer updated the diff for D5084: Finish stable split.

Fix up the comparison business

Aug 27 2018, 3:02 PM

Aug 24 2018

dfeuer added a comment to D5084: Finish stable split.

I put the FFI functions back, with the same names, but only locking and unlocking the stable pointer table, since there's no other FFI access to the stable name table. I also split the last little header file that held these tables together.

Aug 24 2018, 2:44 PM
dfeuer updated the diff for D5084: Finish stable split.
  • Clean up
Aug 24 2018, 2:29 PM

Aug 23 2018

dfeuer added inline comments to D5084: Finish stable split.
Aug 23 2018, 7:34 PM

Aug 22 2018

dfeuer added a comment to D5084: Finish stable split.

@bgamari, what do you know about the FFI bits I tentatively removed? Should I put them back (locking and unlocking both tables)? Should I (alternatively or in addition) add the ability to lock and unlock the tables separately?

Aug 22 2018, 10:12 AM

Aug 21 2018

dfeuer added a comment to D5084: Finish stable split.

I should also split includes/rts/Stable.h. That's pretty trivial.

Aug 21 2018, 11:41 PM
dfeuer created D5084: Finish stable split.
Aug 21 2018, 10:53 PM
dfeuer added a comment to D5081: Use pointer equality to compare StableNames.

You surely need a long Note to explain the moving parts here :-). See the email thread.

Eg what do the entires in the stable name table actually look like? What's this fixedHdrSizeW offset doing? It's all very mysterious

Aug 21 2018, 3:30 AM
dfeuer added a comment to D5081: Use pointer equality to compare StableNames.

Well, it certainly looks like it works. I checked that there are indeed some tests that exercise the stable name mechanism, but it would still be nice if one of the people who has worked on it could confirm that this is really valid.

Aug 21 2018, 1:30 AM

Aug 20 2018

dfeuer created D5081: Use pointer equality to compare StableNames.
Aug 20 2018, 7:28 PM
dfeuer committed rGHC9c4e6c6b1aff: Expose the StableName constructor (authored by dfeuer).
Expose the StableName constructor
Aug 20 2018, 7:09 PM
dfeuer closed D5078: Expose the StableName constructor.
Aug 20 2018, 7:09 PM
dfeuer added a comment to D5078: Expose the StableName constructor.

@osa1, I don't know of a ticket, but there's an accepted GHC proposal.

Aug 20 2018, 2:13 AM

Aug 19 2018

dfeuer added a reviewer for D5078: Expose the StableName constructor: andrewthad.
Aug 19 2018, 5:16 PM
dfeuer created D5078: Expose the StableName constructor.
Aug 19 2018, 4:27 PM

Aug 3 2018

dfeuer accepted D5038: CSE should deal with letrec.

Much better!

Aug 3 2018, 4:17 AM

Aug 2 2018

dfeuer requested changes to D5038: CSE should deal with letrec.

I think there should also be one or two tests that don't rely on all the details of this particular case. To begin with, there should surely be a simple example of defining the same recursive function twice with different names.

Aug 2 2018, 12:22 PM

Jul 26 2018

dfeuer added a reverting change for D3001: Make tickishContains faster: rGHCDIFF99f818282673: Partially revert D3001.
Jul 26 2018, 6:26 PM

Jul 21 2018

dfeuer committed rGHC5a49651f3161: Harden fixST (authored by dfeuer).
Harden fixST
Jul 21 2018, 2:47 PM
dfeuer closed D4948: Harden fixST.
Jul 21 2018, 2:47 PM

Jul 18 2018

dfeuer added a comment to D4967: Use a priority queue for Windows delays.

@Phyx should have a look at this. Also, can you run a benchmark? It's easy to make things theoretically faster but practically slower.

I believe there were people working on porting the IO manager to Windows which would presumably make this redundant, but I'm not sure what the status of those efforts is, perhaps @Phyx knows.

Jul 18 2018, 7:48 AM

Jul 17 2018

dfeuer added a comment to D4967: Use a priority queue for Windows delays.

@simonmar, I see what you likely mean about the PSQ implementation now: it has the advantage of being specialized to fixed-width priorities. We could probably find/create something similarly appropriate for the Windows module, but I don't have the time to invest in it right now (note: we'd need something with a merge operation to maintain the current behavior; the PSQs here don't currently have one).

Jul 17 2018, 7:04 PM
dfeuer updated the diff for D4967: Use a priority queue for Windows delays.

Another fixup

Jul 17 2018, 4:56 PM

Jul 16 2018

dfeuer updated the diff for D4967: Use a priority queue for Windows delays.

Fix -Wall

Jul 16 2018, 1:39 PM
dfeuer updated the diff for D4967: Use a priority queue for Windows delays.

Remove module import cycle

Jul 16 2018, 12:22 PM
dfeuer updated the diff for D4967: Use a priority queue for Windows delays.

Fix module name; add documentation.

Jul 16 2018, 9:48 AM
dfeuer added a comment to D4967: Use a priority queue for Windows delays.

It doesn't look like this compiles.

Did you consider using GHC.Event.PSQ instead?

Jul 16 2018, 6:57 AM

Jul 15 2018

dfeuer created D4967: Use a priority queue for Windows delays.
Jul 15 2018, 12:47 PM
dfeuer committed rGHCaf9b744bbf1c: Replace atomicModifyMutVar# (authored by dfeuer).
Replace atomicModifyMutVar#
Jul 15 2018, 9:19 AM
dfeuer closed D4884: Replace atomicModifyMutVar#.
Jul 15 2018, 9:19 AM

Jul 14 2018

dfeuer added inline comments to D4884: Replace atomicModifyMutVar#.
Jul 14 2018, 8:36 PM

Jul 13 2018

dfeuer updated the diff for D4884: Replace atomicModifyMutVar#.
  • Restore original semantics
Jul 13 2018, 10:05 PM
dfeuer added a comment to D4884: Replace atomicModifyMutVar#.

I've restored the original semantics for now. We can revisit that later. The latest version is less aggressive, but at least shouldn't have the earlier regression.

Jul 13 2018, 10:05 PM
dfeuer added a comment to D4884: Replace atomicModifyMutVar#.

I just realized my last change makes a slight semantic difference, but one I expect is probably tolerable. With the old version,

Jul 13 2018, 3:52 PM
dfeuer requested review of D4884: Replace atomicModifyMutVar#.

@simonmar, I realized last night that my nice, simple definition of atomicModifyIORef' could lead to extra thunks in certain cases. I believe I've cleaned that up, but I'd appreciate a second look.

Jul 13 2018, 2:01 PM
dfeuer updated the diff for D4884: Replace atomicModifyMutVar#.
  • Tweak the definition of atomicModifyIORef'
Jul 13 2018, 1:48 PM

Jul 12 2018

dfeuer added inline comments to D4884: Replace atomicModifyMutVar#.
Jul 12 2018, 10:33 PM
dfeuer added a comment to D4884: Replace atomicModifyMutVar#.

For atomicSwapMutVar# it looks like we don't have the right primitive in Cmm yet, namely %xchg. I suppose we could defer that for a separate diff?

What testing do we have for atomicModifyIORef and friends? It would be good to have some tests to check the strictness properties at least.

Jul 12 2018, 11:10 AM
dfeuer added inline comments to D4884: Replace atomicModifyMutVar#.
Jul 12 2018, 11:07 AM

Jul 11 2018

dfeuer updated the diff for D4884: Replace atomicModifyMutVar#.

Fix atomicModifyIORef' strictness

Jul 11 2018, 5:49 PM
dfeuer added inline comments to D4884: Replace atomicModifyMutVar#.
Jul 11 2018, 5:17 PM
dfeuer updated the summary of D4884: Replace atomicModifyMutVar#.
Jul 11 2018, 2:44 PM
dfeuer added a comment to D4884: Replace atomicModifyMutVar#.

@simonmar, @fryguybob, I've implemented atomicModifyMutVar2# and atomicModifyMutVar_#, but I could use some help with atomicSwapMutVar#. Could one of you give me a hand?

Jul 11 2018, 2:18 PM
dfeuer updated the diff for D4884: Replace atomicModifyMutVar#.

Implement atomicModifyMutVar_#, change some names, and remove the
unaccepted additions to Data.IORef.

Jul 11 2018, 2:13 PM

Jul 10 2018

dfeuer updated the diff for D4948: Harden fixST.
  • Back out lazy ST changes
Jul 10 2018, 3:59 PM
dfeuer updated the diff for D4948: Harden fixST.
  • Back out lazy ST changes
Jul 10 2018, 3:55 PM
dfeuer planned changes to D4948: Harden fixST.

Oh, bleh! I just realized my lazy version is still wrong. It's too strict sometimes, and I think it can also have trouble from the putMVar not actually happening. What a mess....

Jul 10 2018, 2:09 PM
dfeuer added a comment to D4948: Harden fixST.

Can you add a test please?

Jul 10 2018, 1:39 PM
dfeuer updated the diff for D4948: Harden fixST.
  • Fix lazy ST; add tests
Jul 10 2018, 1:39 PM

Jul 9 2018

dfeuer created D4948: Harden fixST.
Jul 9 2018, 1:13 PM

Jun 29 2018

dfeuer committed rGHC6bb0c5db818c: Don't lock the MVar closure on tryReadMVar (authored by dfeuer).
Don't lock the MVar closure on tryReadMVar
Jun 29 2018, 1:33 PM