[petsc-dev] http://petsc.cs.iit.edu/petsc/petsc-dev/rev/a36eb42b26ee

Barry Smith bsmith at mcs.anl.gov
Thu Jun 7 18:24:19 CDT 2012

  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.


On Jun 7, 2012, at 5:45 PM, Jed Brown wrote:

> Did we just adopt a new line formatting convention and nobody told me?
>           ierr = PetscObjectGetOptionsPrefix((PetscObject)(ilink->ksp),&prefix); CHKERRQ(ierr);
>           ierr = PetscObjectSetOptionsPrefix((PetscObject)(dms[i]), prefix);     CHKERRQ(ierr);
>           ierr = KSPSetDM(ilink->ksp, dms[i]);                                   CHKERRQ(ierr);
>           ierr = KSPSetDMActive(ilink->ksp, PETSC_FALSE);                        CHKERRQ(ierr);
>           ierr = PetscObjectIncrementTabLevel((PetscObject)dms[i],(PetscObject)ilink->ksp,0); CHKERRQ(ierr);
>         }
>         else {
>         if(jac->reset)  
>           SETERRQ(((PetscObject)pc)->comm,PETSC_ERR_SUP,"Cases not yet handled when PCReset() was used");
> 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).
> Is the tab level above even correct? Why would the KSP tab level be expected to match the DM tab level?
> 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.

More information about the petsc-dev mailing list