Well for new features like this (rather than bug fix), I&#39;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&#39;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">&lt;<a>carter.schonwald@gmail.com</a>&gt;</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&#39;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">&lt;<a>carter.schonwald@gmail.com</a>&gt;</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">&lt;<a>rrnewton@gmail.com</a>&gt;</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&#39;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&#39;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&#39;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">&lt;<a>rrnewton@gmail.com</a>&gt;</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">&lt;<a>carter.schonwald@gmail.com</a>&gt;</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&#39;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 &quot;isThreadedRTS:: Bool&quot;, )  or some sort of analogue thereof?  </div>








</div></blockquote><div><br></div></div>&lt;</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>