On Fri, 8 Jan 2016, Roy Stogner wrote:
> Let me try putting that overload into Hilbert instead of libMesh and
> see if it works for me. If it does then I'll upload a pull request
> and we can see if it works for you too.
It does work for me. See if
https://github.com/libMesh/libmesh/pull/771
On Fri, 8 Jan 2016, Xujun Zhao wrote:
Again, if I build the library with "dbg" option. Here are the messages:
This is extremely helpful, thanks!
./include/libmesh/parallel_hilbert.h:84:1: note: 'operator<<' should be
declared prior to the call site or
in namespace 'Hilbert'
It loo
Again, if I build the library with "dbg" option. Here are the messages:
*./include/libmesh/ostream_proxy.h:116:16: **error: **call to function
'operator<<' that is neither visible in*
* the template definition nor found by argument-dependent lookup*
(*_target) << in;
* ^*
I updated my Xcode and Command Line Tools by mistake. This is boring every
time. Now I have turned the autocheck off.
I am not sure if there is the same problem on other Macbooks, it is
probably difficult to persuade people around me to upgrade, especially if
they can see this post :-)
On Thu, J
> On Jan 7, 2016, at 8:21 PM, Roy Stogner wrote:
>
>
>> On Thu, 7 Jan 2016, Xujun Zhao wrote:
>>
>> I did try to comment on line 615-618 in mesh_communication_global_indices.C.
>> However, other lines which have libMesh::err <<, for example, line
>> 620-623, line 649-655 ..., led to the simi
On Thu, 7 Jan 2016, Xujun Zhao wrote:
I did try to comment on line 615-618 in mesh_communication_global_indices.C. However,
other lines which have libMesh::err <<, for example, line
620-623, line 649-655 ..., led to the similar error messages. That is why I
comment on that single line in ostr
Hi John and Roy,
I did try to comment on line 615-618 in mesh_communication_global_indices.C.
However, other lines which have libMesh::err <<, for example, line 620-623,
line 649-655 ..., led to the similar error messages. That is why I comment
on that single line in ostream_proxy.h.
After instal
On Thu, 7 Jan 2016, Roy Stogner wrote:
> If you want to help us replicate/fix the problem then we need to know
> what version (release number if you're using a tarball, or git hash
> otherwise) of libMesh you're using.
Never mind this; from context it's obvious that you've found a problem
with t
On Thu, 7 Jan 2016, John Peterson wrote:
> Hmm... the error seems to be triggered by this line of code:
>
> libMesh::err << "node " << (*nodej)->id() << ", " <<
>*(Point *)(*nodej) << " has HilbertIndices " <<
>node_keys[j] << std::endl;
>
On Thu, 7 Jan 2016, Xujun Zhao wrote:
> If I go the file and comment the line (*_target) << in;
> it can pass the compilation on my Mac
You definitely *don't* want to comment out that line; that would
disable most libMesh stdout/stderr messages.
You could, however, comment out just the HilbertI
On Thu, Jan 7, 2016 at 3:20 PM, Xujun Zhao wrote:
> Hi all,
>
> I am reporting a compiling error with Xcode command line tools version 7.2
> Apple LLVM version 7.0.2 (clang-700.1.81)
>
> The configure log file is attached, and the error messages are as follows.
> If I go the file and comment the
Hi all,
I am reporting a compiling error with Xcode command line tools version 7.2
Apple LLVM version 7.0.2 (clang-700.1.81)
The configure log file is attached, and the error messages are as follows.
If I go the file and comment the line (*_target) << in;
it can pass the compilation on my Mac
--
Hi,
The modified code seems to be working.
Thanks,
Subramanya
On Oct 28, 2013, at 5:15 PM, Manav Bhatia wrote:
> It appears that unget() calls the sungetc() on the streambuf class, and sets
> the badbit if streambuf is null.
>
> I am guessing that if the implementation chooses to set the
It appears that unget() calls the sungetc() on the streambuf class, and
sets the badbit if streambuf is null.
I am guessing that if the implementation chooses to set the streambuf to
null after a seekg() (because no characters have been read), then calling
unget() would set the badbit. If this is
>
>
> Note that we are still calling unget(). The only thing I removed was an
> (apparently) redundant tellg/seekg pairing...
>
Ahh... I see that I had missed your point. That is a good catch... and
thanks for clarifying!
-Manav
---
On Mon, Oct 28, 2013 at 2:55 PM, Subramanya Sadasiva wrote:
>
> Is the code already in the repository to be checked out?
>
Yes, in fac138b011.
--
John
--
Android is increasing in popularity, but the open development pla
Is the code already in the repository to be checked out?
-Subramanya
On Oct 28, 2013, at 4:20 PM, Manav Bhatia wrote:
>
>
> On Mon, Oct 28, 2013 at 2:53 PM, John Peterson wrote:
>
>
> One possible problem I can see with the getpot code: is it legal C++ to call
> unget() immediately afte
> On Oct 28, 2013, at 2:20 PM, Manav Bhatia wrote:
>
>
>
>> On Mon, Oct 28, 2013 at 2:53 PM, John Peterson wrote:
>>
>>
>> One possible problem I can see with the getpot code: is it legal C++ to call
>> unget() immediately after a call to seekg or is it possibly invoking
>> undefined beh
On Mon, Oct 28, 2013 at 2:53 PM, John Peterson wrote:
>
>
> One possible problem I can see with the getpot code: is it legal C++ to
> call unget() immediately after a call to seekg or is it possibly invoking
> undefined behavior?
>
>
The purpose of unget() seems to be to decrease position of ist
Will do,
Thanks,
Subramanya
On Oct 28, 2013, at 2:53 PM, John Peterson wrote:
>
>
>
> On Sat, Oct 26, 2013 at 10:36 PM, Manav Bhatia wrote:
> Good to know about this!
>
> I did a bit of digging into it, and the problem seems to be coming after the
> call to istr.unget() at line 990 in G
On Sat, Oct 26, 2013 at 10:36 PM, Manav Bhatia wrote:
> Good to know about this!
>
> I did a bit of digging into it, and the problem seems to be coming after
> the call to istr.unget() at line 990 in GetPot::_skip_whitespace(). For
> some reason, it seems to corrupt the istream data structure so t
On Sun, Oct 27, 2013 at 4:50 PM, Manav Bhatia wrote:
> I had sent an email to the developer of GetPot describing the situation.
> He has an updated version of the code that he has been working on, but he
> is yet to release it on his website. He shared it with me and it works
> without any proble
Date: Mon, 28 Oct 2013 00:35:11 -0400
>> CC: libmesh-users@lists.sourceforge.net
>> Subject: Re: [Libmesh-users] compiling error
>>
>> I just tried clang-3.3 on a linux machine and getpot worked without any
>> issues. This seems to be some apple specific thing. -Subra
On Sun, 27 Oct 2013, subramanya sadasiva wrote:
>> In any case, I have requested him to release the code, and perhaps
>> it will be a good idea to include that update in libMesh.
A good idea, but probably not a possible idea. We had to fork GetPot
from quite a few versions back after discoverin
gt; To: bhatiama...@gmail.com
> Date: Mon, 28 Oct 2013 00:35:11 -0400
> CC: libmesh-users@lists.sourceforge.net
> Subject: Re: [Libmesh-users] compiling error
>
> I just tried clang-3.3 on a linux machine and getpot worked without any
> issues. This seems to be some apple spe
I just tried clang-3.3 on a linux machine and getpot worked without any issues.
This seems to be some apple specific thing. -Subramanya
Subject: Re: [Libmesh-users] compiling error
From: bhatiama...@gmail.com
Date: Sun, 27 Oct 2013 18:59:29 -0400
CC: codyperm...@gmail.com; libmesh-users
m...@gmail.com
> > CC: libmesh-users@lists.sourceforge.net
> > Subject: Re: [Libmesh-users] compiling error
> >
> > I had sent an email to the developer of GetPot describing the situation. He
> > has an updated version of the code that he has been working on, but he is
> > yet
Hi manav, is it possible for you to send the modified version of getpot?
Thanks, Subramanya
> From: bhatiama...@gmail.com
> Date: Sun, 27 Oct 2013 18:50:01 -0400
> To: codyperm...@gmail.com
> CC: libmesh-users@lists.sourceforge.net
> Subject: Re: [Libmesh-users] compiling error
I had sent an email to the developer of GetPot describing the situation. He has
an updated version of the code that he has been working on, but he is yet to
release it on his website. He shared it with me and it works without any
problems with clang5. I have not tried to look at what might be th
We have a few test systems setup at work. Either myself or John can dig in
early next week to get to the bottom of it.
Cody
Sent from my evil iPad
On Oct 27, 2013, at 10:50 AM, Manav Bhatia wrote:
It is based on LLVM 3.3svn. Following is the output of clang —version
Apple LLVM version 5.0 (c
It is based on LLVM 3.3svn. Following is the output of clang —version
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
-Manav
On Oct 27, 2013, at 12:48 PM, Roy Stogner wrote:
>
> On Sun, 27 Oct 2013, Roy Stogner wrote:
>
>> On Sun, 27 Oct 2013, Cody Permann wrote:
>>
>>> Chan
On Sun, 27 Oct 2013, Roy Stogner wrote:
> On Sun, 27 Oct 2013, Cody Permann wrote:
>
>> Chances are that Getpot is doing something wrong and well just have
>> to continue digging to find it. Oh the joy of being an early
>> adopter. :-)
>
> Has anyone tried clang 5.0 on Linux to see if the proble
On Sun, 27 Oct 2013, Cody Permann wrote:
> Chances are that Getpot is doing something wrong and well just have
> to continue digging to find it. Oh the joy of being an early
> adopter. :-)
Has anyone tried clang 5.0 on Linux to see if the problem is
reproduceable there? I do occasional testing
t; early adopter. :-)
>
> Don't give up yet!
> Cody
>
> Sent from my iPhone
>
>> On Oct 26, 2013, at 10:50 PM, subramanya sadasiva
>> wrote:
>>
>> I localized the problem to roughly the same location. This is a bit sad,
>> because it is just
t give up yet!
Cody
Sent from my iPhone
> On Oct 26, 2013, at 10:50 PM, subramanya sadasiva wrote:
>
> I localized the problem to roughly the same location. This is a bit sad,
> because it is just so much nicer working with clang than with gcc..
> Subject: Re: [Libmesh-users]
I localized the problem to roughly the same location. This is a bit sad,
because it is just so much nicer working with clang than with gcc..
Subject: Re: [Libmesh-users] compiling error
From: bhatiama...@gmail.com
Date: Sun, 27 Oct 2013 00:36:13 -0400
CC: libmesh-users@lists.sourceforge.net
To
t; CC: libmesh-users@lists.sourceforge.net
> > Subject: Re: [Libmesh-users] compiling error
> >
> > Hi Manav, I see what you mean. With clang 5.0, getpot is failing. all the
> > parameters are getting set to the default value. Thanks, Subramanya
> > Subject: Re: [Libmesh-user
gt; Subject: Re: [Libmesh-users] compiling error
>
> Hi Manav, I see what you mean. With clang 5.0, getpot is failing. all the
> parameters are getting set to the default value. Thanks, Subramanya
> Subject: Re: [Libmesh-users] compiling error
> From: bhatiama...@gmail.com
> Date: Sat
Hi Manav, I see what you mean. With clang 5.0, getpot is failing. all the
parameters are getting set to the default value. Thanks, Subramanya
Subject: Re: [Libmesh-users] compiling error
From: bhatiama...@gmail.com
Date: Sat, 26 Oct 2013 21:34:48 -0400
CC: jwpeter...@gmail.com; libmesh-users
r...@gmail.com
> > CC: libmesh-users@lists.sourceforge.net
> > Subject: Re: [Libmesh-users] compiling error
> >
> > It seems like this compilation error was introduced with the monitor
> > updates.
> >
> > I am compiling with disable-default-comm-world, wit
I was just able to compile with clang on OS X 10.9 with no problems. Were you
guys able to push the changes?Subramanya
> From: bhatiama...@gmail.com
> Date: Fri, 25 Oct 2013 19:34:58 -0400
> To: jwpeter...@gmail.com
> CC: libmesh-users@lists.sourceforge.net
> Subject: Re:
It seems like this compilation error was introduced with the monitor updates.
I am compiling with disable-default-comm-world, with which the petsc vector
constructor is expecting a second argument.
adding a second argument of "solver.comm()" to the instantiation of PetscVector
at lines 65, 71
On Fri, Oct 25, 2013 at 4:43 PM, Manav Bhatia wrote:
> No, everything is real valued. I updated to the latest OS couple of days
> ago, and this morning did "git pull”, followed by make.
>
I'd definitely blow away any old build directories and rerun configure if
you upgraded your OS... but mayb
No, everything is real valued. I updated to the latest OS couple of days ago,
and this morning did "git pull”, followed by make.
I will dig a bit more to see if I can figure something out. Will keep you
posted.
-Manav
On Oct 25, 2013, at 6:40 PM, John Peterson wrote:
>
>
>
> On Fri,
On Fri, Oct 25, 2013 at 4:17 PM, Manav Bhatia wrote:
> Hi,
>
> I am getting the following error while compiling the latest from git. I
> am using Apple’s clang++ 5.0 on OS X 10.9.
>
> Has anyone else seen this?
>
Nope. Are you possibly compiling libmesh with complex enabled, but you
don't h
Hi,
I am getting the following error while compiling the latest from git. I
am using Apple’s clang++ 5.0 on OS X 10.9.
Has anyone else seen this?
Thanks,
Manav
CXX src/solvers/libmesh_dbg_la-petsc_dm_nonlinear_solver.lo
CXX src/solvers/libmesh_dbg_la-petsc_linear_solver.lo
src/
Dear Libmesh developers,
In order to avoid the multiple definition of `METIS_PartGraphKway' between
the internal library and the petsc library, I use the option
"-with-metis=PETSc". Then I got another errors:
undefined reference to `gk_mcorePush'
undefined reference to `libmetis__isum'
undefined
Well there goes that theory ... you are at least as up-to-date as
whatever we've got in our lab.
-J
On Thu, May 29, 2008 at 9:10 AM, Paulo Correia <[EMAIL PROTECTED]> wrote:
> On Thu, 29 May 2008 08:33:16 -0500
> "John Peterson" <[EMAIL PROTECTED]> wrote:
>
>> Hmm... what compiler and version y
On Thu, 29 May 2008 08:33:16 -0500
"John Peterson" <[EMAIL PROTECTED]> wrote:
> Hmm... what compiler and version you are attempting to use, and what OS?
-bash-3.2$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--info
Hmm... what compiler and version you are attempting to use, and what OS?
Libmesh includes the newer style header instead of "math.h,"
I'm (wildly) guessing it could be tangentially related to your problem
due to the error messages you received?
As I believe Derek mentioned, upgrading to a newer
On Thu, 29 May 2008, Paulo Correia wrote:
>
> Finally after getting rid of all the fe_xyz references I come to the
> following error:
>
> Compiling C++ (in optimized mode) src/base/libmesh.C...
> "/usr/include/bits/cmathcalls.h", line 54: error: expected a ";"
> __MATHCALL (cacos, (_Mdouble_co
Finally after getting rid of all the fe_xyz references I come to the following
error:
Compiling C++ (in optimized mode) src/base/libmesh.C...
"/usr/include/bits/cmathcalls.h", line 54: error: expected a ";"
__MATHCALL (cacos, (_Mdouble_complex_ __z));
^
"/usr/include/bits/cmathcalls.h", lin
Is it actually failing to link? (ie the libmesh.so/.a wasn't
created). Every time I've seen this "discarded section" nonsense (not
just with libMesh but also with other code projects I've worked on)
I've basically been able to ignore it.
I've never been able to get a straight answer about w
On Wed, 28 May 2008, Paulo Correia wrote:
> I get a lot of error messages like this
>
> `.gnu.linkonce.t.__CPR117__n_dofs__53FE__tm__43_XCUiL_1_3XCQ2_12libMeshEnums8FEFamilyL_1_0SFQ2_J35J8ElemTypeQ2_J35J5Order_Ui'
> referenced in section `.text' of
> src/fe/fe_xyz.x86_64-unknown-linux-gnu.opt.o
On Wed, May 28, 2008 at 9:07 AM, Paulo Correia <[EMAIL PROTECTED]> wrote:
>
> I get a lot of error messages like this
>
> `.gnu.linkonce.t.__CPR117__n_dofs__53FE__tm__43_XCUiL_1_3XCQ2_12libMeshEnums8FEFamilyL_1_0SFQ2_J35J8ElemTypeQ2_J35J5Order_Ui'
> referenced in section `.text' of
> src/fe/fe_xy
I get a lot of error messages like this
`.gnu.linkonce.t.__CPR117__n_dofs__53FE__tm__43_XCUiL_1_3XCQ2_12libMeshEnums8FEFamilyL_1_0SFQ2_J35J8ElemTypeQ2_J35J5Order_Ui'
referenced in section `.text' of src/fe/fe_xyz.x86_64-unknown-linux-gnu.opt.o:
defined in discarded section
`.gnu.linkonce.t.__C
56 matches
Mail list logo
