- User Since
- Sep 5 2014, 5:38 PM (214 w, 4 d)
Tue, Oct 9
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.
Mon, Oct 8
Fri, Oct 5
The small type optimization is low priority. I realized we never use dataToTag# for small types in Ord deriving anyway!
Thu, Oct 4
Mon, Sep 17
Sep 14 2018
@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?
- Split differential; rebase; revert silliness
Sep 10 2018
I had to make some changes. Could someone please have another look?
Sep 9 2018
- Hopefully this is the last
The StableName type in base needs to go back to having a representational parameter. The stable-maps package relies on that for safety.
Aug 30 2018
Aug 29 2018
- Don't bother trying to deprecate the C stuff. It seems tricky.
Aug 28 2018
- Remove outdated comment
@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?
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?
@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 27 2018
- Document unsafe stable pointer operations
- Document unsafe stable pointer operations
I've folded this into D5084.
Fix up the comparison business
Aug 24 2018
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 23 2018
Aug 22 2018
@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 21 2018
I should also split includes/rts/Stable.h. That's pretty trivial.
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 20 2018
@osa1, I don't know of a ticket, but there's an accepted GHC proposal.
Aug 19 2018
Aug 3 2018
Aug 2 2018
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.
Jul 26 2018
Jul 21 2018
Jul 18 2018
Jul 17 2018
@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 16 2018
Remove module import cycle
Fix module name; add documentation.
Jul 15 2018
Jul 14 2018
Jul 13 2018
- Restore original semantics
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.
I just realized my last change makes a slight semantic difference, but one I expect is probably tolerable. With the old version,
@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.
- Tweak the definition of atomicModifyIORef'
Jul 12 2018
Jul 11 2018
Fix atomicModifyIORef' strictness
Implement atomicModifyMutVar_#, change some names, and remove the
unaccepted additions to Data.IORef.
Jul 10 2018
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 9 2018
Jun 29 2018
Jun 28 2018
I'm getting very inconsistent benchmark results. This does much better and much worse than the current implementation depending on the situation, and I don't yet understand why.