<div dir="ltr">On Mon, Feb 11, 2013 at 5:28 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Mon, Feb 11, 2013 at 4:06 PM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@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"><div>* We have a couple of malloc/free in use:<br>
<a href="http://krupp.iue.tuwien.ac.at/petsc-style/malloc-free.txt" target="_blank">http://krupp.iue.tuwien.ac.at/<u></u>petsc-style/malloc-free.txt</a><br>
Except for the actual implementation of PetscMalloc() and the like somewhere in src/sys/, is there anything I have to keep in mind when fixing the other uses?<br></div></blockquote><div><br></div></div><div>The cases in mesh.c and plex.c are freeing memory allocated by an external library.</div>
</div></div></div></blockquote><div><br></div><div style>Yep, there is no way around this currently.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div>options.c can be processed before the correct malloc implementation has been determined (because it can be a command-line option).</div><div><br></div><div>str.c stuff can be called before PetscInitialize</div>
<div><br></div><div>hash.h is a third-party library that was brought in and was not fully petsc-fied.</div><div><br></div><div>yamlimpls.c is freeing memory allocated by an external library</div><div>
<br></div><div>The tfs stuff was contributed and never petsc-fied. I don't think it's worth doing maintenance on because it will have to be substantially rewritten if someone wants to extend it in a nontrivial way.</div>
<div><br></div><div>That pretty much covers it, so I think PETSc is okay on this front.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<br>
* CHKERRQ is missing at a couple of places:<br>
<a href="http://krupp.iue.tuwien.ac.at/petsc-style/ierr-chkerr.txt" target="_blank">http://krupp.iue.tuwien.ac.at/<u></u>petsc-style/ierr-chkerr.txt</a><br>
I noticed that PetscPrintf() is hardly ever checked for the value of ierr. Is this intentional? If yes, which other functions in PETSc should not be checked for the return value in ierr = ...?<br></div></blockquote><div>
<br></div></div><div>It looks like most of these are accidentally missing. CHKERRABORT can be used when the function does not return PetscErrorCode, but the function should really be fixed to return PetscErrorCode.</div>
<div class="im"><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
* There is quite some dead code around:<br>
<a href="http://krupp.iue.tuwien.ac.at/petsc-style/if0.txt" target="_blank">http://krupp.iue.tuwien.ac.at/<u></u>petsc-style/if0.txt</a><br>
Are there any objections (or even LOUD objections) in removing all blocks which are older than ~1 year?<br></div></blockquote><div><br></div></div><div>This may need to be done on a case by case basis, but most of it can probably go. I wouldn't put any effort into src/dm/impls/{mesh,cartesian} because I suspect that code will be deleted en masse within a year.</div>
</div></div></div></blockquote><div><br></div><div style>1) Don't remove the dead code in ctetgen.c because I still have to turn on some of the cooler features (eventually)</div><div style><br></div><div style>2) mesh will be deleted when PyLith and Blaise have fully converted code. The aim is this summer. I will delete cartesian</div>
<div style> when I have documented the cool Grey code traversals that are buried in there.</div><div style><br></div><div style> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
* src/contrib/markadamscolor/<u></u>color.c is the only place using assert():<br>
<a href="http://krupp.iue.tuwien.ac.at/petsc-style/assert.txt" target="_blank">http://krupp.iue.tuwien.ac.at/<u></u>petsc-style/assert.txt</a><br>
Since color.c entered in the previous century and hasn't been notably touched since at least 2001, is there any reason other than software archeology for keeping it?<br></div></blockquote></div></div><br>I don't know what other people think about the contrib directory. It has a lot of cobwebs in it, but it can be fun to look at sometimes. The FUN3D code in there is now out of date with respect to PETSc and METIS interfaces. Somewhere along the line, comp/flow.c became syntactically incorrect. (Perhaps reformatting interacted poorly its heavy use of macros.)</div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>