On Mon, Jun 21, 2010 at 9:02 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, 21 Jun 2010 20:25:07 +0000, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Mon, Jun 21, 2010 at 5:18 PM, Jed Brown <<a href="mailto:jed@59a2.org">jed@59a2.org</a>> wrote:<br>
><br>
> > Heads up about this namespace collision, seems less appropriate for<br>
> > PETSc to claim Mesh:: than for libMesh.<br>
><br>
><br>
> Crap, its the C side. I hate that anyway. I am cool with changing 'Mesh'<br>
> to 'PetscMesh' since all these C symbols should be properly namespaced<br>
> like my C++.<br>
<br>
</div>Certainly nobody would want to use "ALE::" for say, an Arbitrary<br>
Lagrange Eulerian code, or have a header named Field.hh, Generator.hh,<br>
Mesh.hh, Numbering.hh, etc [1].</blockquote><div><br></div><div>You can say that about any name.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> The only reason that 'Vec' and 'Mat' are not is history and<br>
> convenience. However, I do not buy the appropriateness argument at<br>
> all.<br>
<br>
</div>One could certainly argue that libMesh is a bad (not sufficiently<br>
distinguished) name, but it does produce libmesh.so (not liblibmesh.so)<br>
which makes "Mesh" a reasonably appropriate namespace (not as good as<br>
"libMesh" only because "Mesh" is so common). A PETSc component named<br>
Sieve claiming the namespace "Mesh" is far more of a stretch.<br></blockquote><div><br></div><div>We both do mesh stuff. I do not see why it is "more legitimate" for them to do it.</div><div>The idea is to make it easy to coexist.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Jed<br>
<br>
[1] I suggest #include <sieve/Mesh.hh> if you don't want these header<br>
names to include the PETSc name somehow, now you require that they<br>
-I$PETSC_DIR/include/sieve which makes those header names completely<br>
public.<br></blockquote><div><br></div><div>I thought this was changed for PETSc 3. Now it should be sieve/Mesh.hh. I agree</div><div>the other way is wrong.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On this note, I don't like "private/vecimpl.h", it is much more common<br>
(look at your /usr/include) and collision-free to do "petsc/vecimpl.h"<br>
or even "petsc-private/vecimpl.h".</blockquote><div><br></div><div>I am cool with petsc-private.</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Jed</font></blockquote></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<br>