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. <div><br></div><div><br>On Saturday, August 3, 2013, Carter Schonwald wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">took a quick look, awesome! this will make it MUCH MUCH easier for me to do my work. Thank you very much. <div>
<br></div><div>off hand, to prevent patch confusion,</div><div> it naively seems like the nicest way to post the patches to trac is to post a <b>new ticket to trac</b> that links to the main one,</div>
<div> plus add a comment on the main ticket a link to the new ticket for the c/cmm based versions of the primops.</div><div><br></div><div> 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?</div>
<div><br></div><div>(i'm also possibly over thinking this enormously, so i could be way off base)</div><div><br></div></div><div><br><br><div>On Sat, Aug 3, 2013 at 9:31 PM, Carter Schonwald <span dir="ltr"><<a>carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">nvm, githubs backup, i'll have a look! :)</div><div><div><div>
<br><br><div>On Sat, Aug 3, 2013 at 9:05 PM, Carter Schonwald <span dir="ltr"><<a>carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>awesome! (this will also make my work easier)</div><div><br></div>ryan: github is down, could you put the branch on bitbucket or some such so I can have a lookseee/clone locally?<div>
<br></div><div>
thanks!</div><span><font color="#888888"><div>-Carter</div></font></span></div><div><div><div><br><br><div>On Sat, Aug 3, 2013 at 4:01 AM, Ryan Newton <span dir="ltr"><<a>rrnewton@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Just to keep you all up to date... I'm adding the primops in question and validating the individual commits before putting them here:</div>
<div><div><br></div><div> <a href="https://github.com/rrnewton/ghc/commits/atomicPrimOps" target="_blank">https://github.com/rrnewton/ghc/commits/atomicPrimOps</a><br>
</div><div><br></div><div>The basic idea for using these extensions is:<br></div><div><div><ul><li>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</li>
<li>future versions will simply get faster, as Carter replaces out-of-line primops that *also* use C calls, with inline primops / LLVM equivalents</li></ul></div></div><div>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 <a href="https://github.com/ghc/ghc" target="_blank">warning sign</a> recommends.)</div>
<div><br></div><div>Best,</div><div> -Ryan</div><div><br></div><div><div>P.S. FYI, I'm periodically getting these: </div><div><br></div><div><span style="white-space:pre-wrap"> </span> 0 caused framework failures</div>
<div><span style="white-space:pre-wrap"> </span> 0 unexpected passes</div><div><span style="white-space:pre-wrap"> </span> 1 unexpected failures</div><div><br></div><div> Unexpected failures:</div><div>
<span style="white-space:pre-wrap"> </span>perf/compiler T1969 [stat not good enough] (normal)</div>
</div><div><br></div></div><div>Can that just be because of running on a loaded machine? How narrow are these windows?</div><div><div><div><br></div><div><br><div>
On Thu, Aug 1, 2013 at 12:32 PM, Ryan Newton <span dir="ltr"><<a>rrnewton@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>On Sun, Jul 21, 2013 at 3:32 AM, Carter Schonwald <span dir="ltr"><<a>carter.schonwald@gmail.com</a>></span> wrote:<br>
</div><div>
<div><div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>ok, could you add those comments (about additional operations to consider) to the ticket?</div>
</div>
</blockquote><div><br></div></div><div>Sure. Just did that.</div><div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>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 </div>
<div>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? </div>
</div></blockquote><div><br></div></div><</div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></blockquote></div>
<br><br>-- <br>Sent from Gmail Mobile<br>