[MOAB-dev] iMesh_setAdjTable() causes error in iMesh_load()

[Jed Brown]

On Thu, Jun 9, 2011 at 21:21, Iulian Grindeanu <iulian at mcs.anl.gov> wrote:

> I reproduced the error, I didn't install yet your code.
> (I just used imesh load, after setting the table)
> /*
>  * load_adj.cpp
>  *
>  *  Created on: Jun 9, 2011
>  */
>
> #include "TestRunner.hpp"
>

It's not at all clear how you compile this because it depends through
TestRunner.hpp on a bunch of internal files that are not installed. In some
sense, it look like it is only buildable within the source tree. I see some
ways to improve this process:

1. Install the necessary files so that the tests and examples can be
relocated and compiled using the standard build rules.

2. Make a test of the bug to run in the automated tests. Perhaps that is
excessive in this case, but bear in mind that untested code is usually
broken.

3. Use a distributed SCM with local branches so that you can easily manage
the patch that adds the example/test code. This can be a tiny amount of
work. For example, you could just modify the files in-place, then

$ git checkout -b load-adj-bug
$ git add load_adj.cpp Makefile.am
$ git commit -m'Example demonstrating bug in iMesh_load() after
iMesh_setAdjTable()'
$ git send-email --to jed at 59A2.org HEAD^
$ git checkout master

The last line leaves you back at your clean state without the clutter of
this example that you don't want to push upstream. The "load-adj-bug" branch
lives on, strictly within your local repository, until you delete it (or
merge it), but it's out of the way. If you want to test it against a more
recent copy of MOAB, you can

$ git rebase master load-adj-bug # re-applies the patch (series) to "master"
$ make


While typing this, I have followed the same procedure in the terminal, the
patch for which is attached as a demonstration of the concept. It was about
15 seconds to create and attach the patch and I can apply a patch like this
from email in about five seconds. The difference between minutes and seconds
from email to running code is significant, in my opinion.

Notes:
1. Subversion can create a patch too, but you can't commit it without
sending it upstream, so it's not versioned and recoverable. It's also
completely non-intelligent (because the data model doesn't have the semantic
information) if you want to reapply the patch on a later version of the
source tree.

2. Git can pull and push from a subversion repository so using git locally
is independent of using git on the upstream host.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20110610/7cfef7ed/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Example-demonstrating-bug-in-iMesh_load-after-iMesh_.patch
Type: text/x-patch
Size: 3116 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20110610/7cfef7ed/attachment.bin>