On Thu, Oct 27, 2011 at 11:57 AM, John Peterson wrote:
>
> There's no reason the problem will always be limited to n_dofs(), so
> I'm planning to change all the FE function instantiations to
> specializations. There's also no reason for this problem to be
> limited to Lagrange FEM, so I'm changin
On Thu, 27 Oct 2011, John Peterson wrote:
> On Thu, Oct 27, 2011 at 12:05 PM, Roy Stogner
> wrote:
>>
>> On Thu, 27 Oct 2011, John Peterson wrote:
>>
>>> We're specializing the behavior of n_dofs() for different template
>>> arguments; it follows that we should probably use the template
>>> sp
On Thu, Oct 27, 2011 at 12:05 PM, Roy Stogner wrote:
>
> On Thu, 27 Oct 2011, John Peterson wrote:
>
>> We're specializing the behavior of n_dofs() for different template
>> arguments; it follows that we should probably use the template
>> specialization syntax to do so.
>
> Here's the catch: temp
On Thu, 27 Oct 2011, John Peterson wrote:
> We're specializing the behavior of n_dofs() for different template
> arguments; it follows that we should probably use the template
> specialization syntax to do so.
Here's the catch: template specialization doesn't exist for templated
functions in C++
On Mon, Oct 24, 2011 at 1:01 PM, Jed Brown wrote:
> On Mon, Oct 24, 2011 at 10:24, John Peterson wrote:
>>
>> On Tue, Oct 18, 2011 at 10:18 PM, Jed Brown wrote:
>> >
>> > I rebuilt everything and sadly, the same problem is still present with
>> > r4873.
>>
>> One other difference between Mac and
On Mon, Oct 24, 2011 at 10:24, John Peterson wrote:
> On Tue, Oct 18, 2011 at 10:18 PM, Jed Brown wrote:
> >
> > I rebuilt everything and sadly, the same problem is still present with
> > r4873.
>
> One other difference between Mac and Linux we noted was the ordering
> of linking imposed by make
On Tue, Oct 18, 2011 at 10:18 PM, Jed Brown wrote:
>
> I rebuilt everything and sadly, the same problem is still present with
> r4873.
One other difference between Mac and Linux we noted was the ordering
of linking imposed by make's $(wildcard ) functionality. (This
ordering may also be file-sys
On Oct 14, 2011, at 6:48 AM, John Peterson wrote:
> On Thu, Oct 13, 2011 at 10:26 PM, Roy Stogner
> wrote:
>>
>> On Thu, 13 Oct 2011, Jed Brown wrote:
>>
>>> fe_type = {.order = libMeshEnums::SECOND, .family =
>>> libMeshEnums::LAGRANGE}
>>>
>>> and the value 6 is returned from fe_xyz.C:931
On Thu, Oct 13, 2011 at 10:26 PM, Roy Stogner wrote:
>
> On Thu, 13 Oct 2011, Jed Brown wrote:
>
>> fe_type = {.order = libMeshEnums::SECOND, .family =
>> libMeshEnums::LAGRANGE}
>>
>> and the value 6 is returned from fe_xyz.C:931 by
>
> Here's your problem: the linker isn't calling the right func
On Thu, Oct 13, 2011 at 23:32, Derek Gaston wrote:
> Indeed - I suspected as much.
>
> Are you coming to the meeting tomorrow morning Jed? We can definitely work
> on this some then…
>
Yeah, I'll be there.
I was using gcc-4.6.1 on Arch Linux. I tried to rebuild with clang-2.9, but
ran into -fP
Indeed - I suspected as much.
Are you coming to the meeting tomorrow morning Jed? We can definitely work on
this some then…
Derek
On Oct 13, 2011, at 10:26 PM, Roy Stogner wrote:
>
> On Thu, 13 Oct 2011, Jed Brown wrote:
>
>> fe_type = {.order = libMeshEnums::SECOND, .family = libMeshEnums:
On Thu, 13 Oct 2011, Jed Brown wrote:
fe_type = {.order = libMeshEnums::SECOND, .family = libMeshEnums::LAGRANGE}
and the value 6 is returned from fe_xyz.C:931 by
Here's your problem: the linker isn't calling the right function.
It's a linker problem I've seen before, too, where for some re
I'm tripping an assert that Derek and John are not seeing. From the
debugging session below, I have no idea why, unless they really aren't
building with DEBUG on.
Reproduce with: ./ex3-dbg -d 2
#ifdef DEBUG
libmesh_assert (tot_size == di.size());
#endif
... because tot_size is 6, di.size()
13 matches
Mail list logo
