On Thu, Sep 13, 2012 at 10:08 PM, Roy Stogner wrote:
> Copying this to libmesh-devel in case anyone else has
> ideas/suggestions.
>
Patch that implements this functionality here:
http://users.ices.utexas.edu/~pbauman/qoi.patch
Patch includes a little cleanup/reorg of adjoints_ex2 to test out add
On Thu, Sep 13, 2012 at 10:08 PM, Roy Stogner wrote:
> I'm surprised you didn't just die when
> it ran out of stack space, though; there shouldn't have been any heap
> allocation involved there and I didn't *think* the stack was allowed
> to grow to 12GB by default.
>
Before I pulled my head out
On Thu, 13 Sep 2012, Paul T. Bauman wrote:
> So how would you like the attachment of an external
> DifferentiableQoI to work? I already learned the hard way that
> having an AutoPtr stashed that is initialized with a this pointer is
> a bad idea (it's amazing how quickly it ate up 12GB of RAM).
I think I'd prefer "libmesh/base/dof_map.h", but given time to reflect
I might change my mind, and it looks like I'm outvoted regardless.
---
Roy
--
Live Security Virtual Conference
Exclusive live event will cover all the
On Thu, 13 Sep 2012, Derek Gaston wrote:
On Thu, Sep 13, 2012 at 12:27 PM, Roy Stogner wrote:
Actually, point me to the 2008 thread? It's possible that I was wrong
and have since learned the error of my ways.
http://comments.gmane.org/gmane.comp.mathematics.libmesh.devel/620
On Thu, Sep 13, 2012 at 1:59 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
>
> So, any preferences?
>
> #include "libmesh/dof_map.h"
>
This one is mine.
--
Live Security Virtual Conference
Exclusive li
On Thu, Sep 13, 2012 at 12:59 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> So, any preferences?
>
> #include "libmesh/dof_map.h"
>
> or
>
> #include "libmesh/base/dof_map.h"
>
#include "dof_map.h"
;-)
But seriously... I do like "libmesh/dof_map.h" more than the other as l
>> Another option is to put a "libmesh" symlink underneath include that
>> points to include... so #include "libmesh/base" will work fine...
>> then no source files need to be moved... and you don't have to
>> traverse the extra directory when you're working in libMesh...
Also, WRT:
> How do we
On Thu, Sep 13, 2012 at 12:27 PM, Roy Stogner wrote:
> Vengeance is yours?
>
lol
> Actually, point me to the 2008 thread? It's possible that I was wrong
> and have since learned the error of my ways.
http://comments.gmane.org/gmane.comp.mathematics.libmesh.devel/620
> On the other hand, I
On Thu, 13 Sep 2012, Derek Gaston wrote:
> Hmmm... There was a discussion all the way back in 2008 where I was
> wanting to get better error messages out of libMesh... and Roy shot
> me down ;-)
Vengeance is yours?
Actually, point me to the 2008 thread? It's possible that I was wrong
and have
On Thu, 13 Sep 2012, Derek Gaston wrote:
> Another option is to put a "libmesh" symlink underneath include that
> points to include... so #include "libmesh/base" will work fine...
> then no source files need to be moved... and you don't have to
> traverse the extra directory when you're working i
On Thu, Sep 13, 2012 at 12:07 PM, Roy Stogner wrote:
> Move e.g. include/base/ to include/libmesh/base/
> Change the current include path options to match.
> Add another include path of "-I$LIBMESH_DIR/include".
> And add a configure option to remove the current-style paths.
> Done.
>
This seems
On Thu, 13 Sep 2012, Kirk, Benjamin (JSC-EG311) wrote:
>> So basically you have one structure that is good for development (which is
>> the
>> current structure) and then we have another structure that is good for
>> includes that symlinks into the first structure...
>
> I like this idea and am
Hmmm... There was a discussion all the way back in 2008 where I was wanting
to get better error messages out of libMesh... and Roy shot me down ;-)
Instead of specialized assert functions like this (have you been spending
too much time with cpp_unit?? ;-) why not just make libmesh_assert() take a
> So basically you have one structure that is good for development (which is the
> current structure) and then we have another structure that is good for
> includes that symlinks into the first structure...
I like this idea and am working towards something like that...
-Ben
On Thu, Sep 13, 2012 at 11:11 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> Well, if you guys have such a vested interest in insulating Moose users
> from
> our churn, why make them responsible for knowing our header names at all?
>
> You could create your own libmesh.h which
>>> I haven't complained, but I've already hit several cases where I had to
>>> rename
>>> my own header file because it collided with a libMesh header name. This
>>> would
>>> fix any further possibilities of this happening.
>>
>> Likewise. For example, we have 'utility.h' just hanging out ther
On Thu, 13 Sep 2012, John Peterson wrote:
> How 'bout we rename all our headers from foo.h to libmesh_foo.h?
>
> Hmm... originally I was going to post this as a joke, but maybe it's
> simpler than messing with configure/make stuff?
I'd expect it to be much more complex, especially for maintainin
On Thu, Sep 13, 2012 at 10:58 AM, Kirk, Benjamin (JSC-EG311)
wrote:
> On 9/13/12 11:48 AM, "Paul T. Bauman" wrote:
>
>>> Has anyone ever complained about this? What is the use case that is driving
>>> this change?
>
>> I haven't complained, but I've already hit several cases where I had to
>> r
On 9/13/12 11:48 AM, "Paul T. Bauman" wrote:
>> Has anyone ever complained about this? What is the use case that is driving
>> this change?
> I haven't complained, but I've already hit several cases where I had to rename
> my own header file because it collided with a libMesh header name. This
On Thu, Sep 13, 2012 at 11:53 AM, Derek Gaston wrote:
>
> Hmmm that would also mean that you would have a class name that is
> similar / the same as a libmesh class name.
>
Yes, but this is why use namespace religiously.
> Do you not use "using namespace libmesh" ?
>
*NEVER* And I get re
On Thu, 13 Sep 2012, John Peterson wrote:
> Hmm... I wouldn't mind just going cold turkey on switching this over.
Whenever we force people to decide "my code will be compatible with
libMesh versions older than M or with versions newer than N", I
greatly prefer it if N is less than M and if there
Oops - didn't reply all
-- Forwarded message --
From: Derek Gaston
Date: Thu, Sep 13, 2012 at 10:53 AM
Subject: Re: [Libmesh-devel] header file path safety
To: "Paul T. Bauman"
On Thu, Sep 13, 2012 at 10:48 AM, Paul T. Bauman wrote:
> I haven't complained, but I've already hi
On Thu, 13 Sep 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Obviously this won't allow us to have foo.h in multiple directories
> until we totally eliminate the backwards compatibility, but that's
> OK...
Well personally I don't *want* us to ever have foo.h in multiple
directories, I just want user
On Thu, Sep 13, 2012 at 11:45 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
>
>
> But even then when we are building the library internally to the build
> system and the header files have not been redistributed by an install rule
> we'd need to be able to find them, which I thin
On Thu, Sep 13, 2012 at 11:45 AM, Derek Gaston wrote:
> Has anyone ever complained about this? What is the use case that is
> driving this change?
>
I haven't complained, but I've already hit several cases where I had to
rename my own header file because it collided with a libMesh header name.
On 9/13/12 11:39 AM, "Paul T. Bauman" wrote:
> would be fine but would require we create a libmesh directory inside each of
> our current subdirectories, and it is the only thing in there. So we'd have
>
> include/base/* -> include/base/libmesh/*
> include/enums/* -> include/enums/libmesh/*
Firstly... let me say that you guys can do what you like but I'm going
to hardcode whatever paths are necessary into our Makefiles to maintain the
status quo. I don't have any problem with the way it is now... and I
really don't want to have to remember what (sometimes arbitrary) directory
a h
On Thu, Sep 13, 2012 at 11:34 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On 9/13/12 11:19 AM, "John Peterson"
> wrote:
>
> >> #include "libmesh/base/dof_map.h"
> >
> > Better because more unique? Feels a little "boost"y to me, but I
> > guess I could get used to it.
>
>
On 9/13/12 11:19 AM, "John Peterson" wrote:
>> #include "libmesh/base/dof_map.h"
>
> Better because more unique? Feels a little "boost"y to me, but I
> guess I could get used to it.
better because I still want sudirectories to organize the header files.
#include "libmesh/dof_map.h"
would be
On Thu, Sep 13, 2012 at 9:06 AM, Kirk, Benjamin (JSC-EG311)
wrote:
> OK, there might be some resistance to this, but...
>
> I've been thinking about putting a little include file header safety into
> libMesh. Basically, right now all our header files have to have unique
> names because their dire
On Thu, Sep 13, 2012 at 10:36 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
>
> > #include "libmesh/base/dof_map.h"
> > in the long run.
>
> That's easy enough.
>
> the plan would be to make
>
> $LIBMESH_ROOT/include/libmesh
>
> and move our current
>
> $LIBMESH_ROOT/include/*
> #include "libmesh/base/dof_map.h"
> in the long run.
That's easy enough.
the plan would be to make
$LIBMESH_ROOT/include/libmesh
and move our current
$LIBMESH_ROOT/include/* there.
> But from a backwards compatibility standpoint, I always thought it
> would be too tricky to juggle this ar
On Thu, 13 Sep 2012, Kirk, Benjamin (JSC-EG311) wrote:
> OK, there might be some resistance to this, but...
>From a software reusability standpoint, it was a lousy mistake not to
put our headers into the closest thing C/C++ has to a "namespace", and
we should have fixed it around the same time w
OK, there might be some resistance to this, but...
I've been thinking about putting a little include file header safety into
libMesh. Basically, right now all our header files have to have unique
names because their directories get added to the include path. Further, none
of these can have the sa
35 matches
Mail list logo
