>> Speaking of things we don't do or don't want to do during development... >> >> Because we only handle error() ourselves, I found it useful while >> debugging to change a few assert() statements to use a >> libmesh_assert() macro instead, one which (when NDEBUG isn't defined) >> basically does an if(!(...)) on the contents, prints the assertion in >> an error message if the if test succeeds, then hands off to error() >> for stack trace printing, exception throwing, and whatever else we >> decide to do later. >> >> The questions thus raised are: >> >> Do we want to add libmesh_assert() to the library so everyone can use >> this feature? > > Yes!
It's in there. I've also committed the "print_trace() to file during error()" behavior to CVS. It's off by default, but if you configure with --enable-tracefiles and if you're using gcc, you get tracefiles (made unique by libMesh processor_id and OS pid in the filename) from each process that hits the error(). Intel is trying to be ABI compatible with GCC on Linux, right? If they define HAVE_GCC_ABI_DEMANGLE and HAVE_GLIBC_BACKTRACE then maybe they'll work out of the box, but I think in general we'll need a bunch of different implementations in print_trace.C; this stuff isn't very standardized. >> Do we want to search and replace through thousands of existing >> assert() statements so everyone *does* use this feature? >> >> I'd do the work for the latter, since I think it would have the >> potential to downgrade parallel debugging from "huge pain in the ass" >> to just "pain in the ass", but I thought I'd run it by you before >> creating or committing a multi-thousand line changeset. > > Well, as unappealing as it sounds, we need to do it. And while we are > changing basically every file we should replace error() with libmesh_error() > everywhere in the library, and immediately deprecate error(). Will do. The deprecated() macro isn't very useful here, though, since lots of users will have code that never hits error() at all. Perhaps error() should just use a #warning... and for that matter, maybe we should have deprecated() print a warning at compile time in addition to or instead of at runtime. > We can add "include/base/error.h" which has the old error for people > who don't want to change their code. It still bugs me that we have > to use the STLPort implementation within the SunStudio compilers > because they use 'error' as a member variable within their default > STL implementation. I'd rather jump straight from "error() is deprecated but available in libmesh_common.h" in 0.7.0 to "error() isn't available at all, change your code" in whatever release comes months later. Seriously, between assert() and error(), grep says there's going to be about 5000 lines for me to change in library code, and about 1000 lines in my app codes, and I'll have to double-check the results of the search-and-replace one by one to make sure sed isn't overzealous. I know I've been "let's not break the API" guy in the past, but this time think my reaction to users who aren't willing to change their own apps would just be hysterical laughter. > You should probably mention it to the devel-list at-large, though, so folks > know to expect it. I'll Cc: this to the list for comments; I'll post again when I'm done with the changes. --- Roy ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
