huh, did I suggest viewing it as a bug fix? my mistake! (a branch would make sense)
On Sat, Aug 10, 2013 at 12:40 PM, Ryan Newton <rrnew...@gmail.com> wrote: > Well for new features like this (rather than bug fix), I'd prefer if I > could get commit access and at least push it to a branch. I can create a > new trac ticket too. > > > On Saturday, August 3, 2013, Carter Schonwald wrote: > >> took a quick look, awesome! this will make it MUCH MUCH easier for me to >> do my work. Thank you very much. >> >> off hand, to prevent patch confusion, >> it naively seems like the nicest way to post the patches to trac is to >> post a *new ticket to trac* that links to the main one, >> plus add a comment on the main ticket a link to the new ticket for the >> c/cmm based versions of the primops. >> >> At least, given that theres likely going to be a bit of discussion on >> just your ticket perhaps, better to factor that into a related ticket to >> make it easier to keep track of that? >> >> (i'm also possibly over thinking this enormously, so i could be way off >> base) >> >> >> >> On Sat, Aug 3, 2013 at 9:31 PM, Carter Schonwald < >> carter.schonw...@gmail.com> wrote: >> >> nvm, githubs backup, i'll have a look! :) >> >> >> On Sat, Aug 3, 2013 at 9:05 PM, Carter Schonwald < >> carter.schonw...@gmail.com> wrote: >> >> awesome! (this will also make my work easier) >> >> ryan: github is down, could you put the branch on bitbucket or some such >> so I can have a lookseee/clone locally? >> >> thanks! >> -Carter >> >> >> On Sat, Aug 3, 2013 at 4:01 AM, Ryan Newton <rrnew...@gmail.com> wrote: >> >> Just to keep you all up to date... I'm adding the primops in question >> and validating the individual commits before putting them here: >> >> https://github.com/rrnewton/ghc/commits/atomicPrimOps >> >> The basic idea for using these extensions is: >> >> - the atomic-primops library will work in 7.6 or 7.7+. It will use >> ifdefs to decide whether to use its own primops or GHC-builtin >> - future versions will simply get faster, as Carter replaces >> out-of-line primops that *also* use C calls, with inline primops / LLVM >> equivalents >> >> Shall I stick a patch on a ticket, or will someone volunteer to pull? >> What's the protocol for requesting commit access anyway? (By the way, can >> someone share the reason that pull-requests to the github ghc mirror are >> such a no-no? They seem no worse than a patch in an email which the big >> warning >> sign <https://github.com/ghc/ghc> recommends.) >> >> Best, >> -Ryan >> >> P.S. FYI, I'm periodically getting these: >> >> 0 caused framework failures >> 0 unexpected passes >> 1 unexpected failures >> >> Unexpected failures: >> perf/compiler T1969 [stat not good enough] (normal) >> >> Can that just be because of running on a loaded machine? How narrow are >> these windows? >> >> >> On Thu, Aug 1, 2013 at 12:32 PM, Ryan Newton <rrnew...@gmail.com> wrote: >> >> On Sun, Jul 21, 2013 at 3:32 AM, Carter Schonwald < >> carter.schonw...@gmail.com> wrote: >> >> ok, could you add those comments (about additional operations to >> consider) to the ticket? >> >> >> Sure. Just did that. >> >> >> relatedly: if we want these atomic ops to use the sequential analogues >> when we're not using the threaded run time system, does that mean >> we need to have a symbol / constant variable exposed in the RTS we link >> in, so that the inline code branches on a linktime constant value / symbol >> (something like "isThreadedRTS:: Bool", ) or some sort of analogue >> thereof? >> >> >> < >> >> > > -- > Sent from Gmail Mobile >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
