When can we expect that (I mean 4.0)?<div>Moose now rejects commits with trailing white space.</div><div>Dmitry.</div><div><br><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 6:24 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  For PETSc 4.0 we adopt an appropriate "pre-commit" source code pretty print system; that prevents incorrectly formatted code from getting into the repository.<br>
<span class="HOEnZb"><font color="#888888"><br>
  Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Jun 7, 2012, at 5:45 PM, Jed Brown wrote:<br>
<br>
> Did we just adopt a new line formatting convention and nobody told me?<br>
><br>
>           ierr = PetscObjectGetOptionsPrefix((PetscObject)(ilink->ksp),&prefix); CHKERRQ(ierr);<br>
>           ierr = PetscObjectSetOptionsPrefix((PetscObject)(dms[i]), prefix);     CHKERRQ(ierr);<br>
>           ierr = KSPSetDM(ilink->ksp, dms[i]);                                   CHKERRQ(ierr);<br>
>           ierr = KSPSetDMActive(ilink->ksp, PETSC_FALSE);                        CHKERRQ(ierr);<br>
>           ierr = PetscObjectIncrementTabLevel((PetscObject)dms[i],(PetscObject)ilink->ksp,0); CHKERRQ(ierr);<br>
><br>
>         }<br>
>         else {<br>
><br>
>         if(jac->reset)<br>
>           SETERRQ(((PetscObject)pc)->comm,PETSC_ERR_SUP,"Cases not yet handled when PCReset() was used");<br>
><br>
> Knowing Barry, he's going to fix this formatting the next time he runs across that file just to make it consistent (at the unfortunate expense of making "hg annotate" less useful until the tools get better about tracing backward through history).<br>


><br>
> Is the tab level above even correct? Why would the KSP tab level be expected to match the DM tab level?<br>
><br>
> Do we need this new set of KSP-specific functions for manipulating tab levels? There isn't a KSPTypeCompare(), etc. I thought the convention within PETSc was that user-level APIs were usually exposed as type-specific routines, but developer-level stuff used PetscObject directly.<br>


><br>
<br>
</div></div></blockquote></div><br></div>