Hmmm - something is kind of weird here. It looks like you've left in the
prepare_for_use() argument to skip_renumber... but it doesn't work. If I
call prepare_for_use(true) I get renumbering. If, right before that, I
call allow_renumbering(false) then everything works fine. Does that make
sense?
I vote for just removing the argument to prepare_for_use() at this point.
Leaving it there caused our stuff to break because it wasn't a compile
error... but it doesn't do what it used to do.
Derek
On Thu, Oct 18, 2012 at 11:28 AM, Roy Stogner <royst...@ices.utexas.edu>wrote:
>
> On Thu, 18 Oct 2012, Derek Gaston wrote:
>
> Go ahead and check in your change for renumbering. We'll fix our stuff
>> afterward.
>>
>
> I'll break your stuff by Monday, then. ;-)
>
>
> As for constraints - we don't use any of those functions.
>>
>> Thanks for keeping us in mind on these changes!
>>
>
> No problem!
>
> I wonder if we should find or invent some standard way of specifying
> what's an "internal" vs. "external" API. public/protected/private
> doesn't quite cut it, since we have lots of methods (like those
> constraints functions) that need to be called from other libMesh
> components but aren't designed for user access. I'm not sure I'd want
> to *prohibit* application code from calling such functions (although
> that one Ulrich Drepper paper suggests minor speed improvements from
> hiding symbols) but it might be nice to easily indicate which APIs we
> wrote with users in mind vs which we consider risky to call from app
> code.
> ---
> Roy
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
