On Thu, Oct 4, 2012 at 3:28 PM, Cody Permann wrote:
> So I went through the process of updating Fparser today (Version 4.3.3 ->
> 4.5) in an attempt to figure out why our compiler stack wouldn't compile it
> in debug mode. I have successfully tested this update on Linux/GNU, OS
> X/Apple-GCC, an
On Thu, 4 Oct 2012, Cody Permann wrote:
> Ok - I lied, two, and they probably both can be removed.
One can't be removed without either breaking stuff or writing our own
Makefile entries to handle what the original author presumably does by
hand. The other, I'm not sure what it's for, but I'd ra
On Thu, Oct 4, 2012 at 4:10 PM, Cody Permann wrote:
>
>
> On Thu, Oct 4, 2012 at 4:06 PM, Roy Stogner wrote:
>
>>
>> On Thu, 4 Oct 2012, Cody Permann wrote:
>>
>> The patch is way to big to attach here, but are there any comments
>>> before I commit to trunk?
>>>
>>
>> For anyone else who's curi
On Thu, Oct 4, 2012 at 4:06 PM, Roy Stogner wrote:
>
> On Thu, 4 Oct 2012, Cody Permann wrote:
>
> The patch is way to big to attach here, but are there any comments
>> before I commit to trunk?
>>
>
> For anyone else who's curious, I had Cody send me a copy you could
> look over here:
>
> http:/
On Thu, 4 Oct 2012, Cody Permann wrote:
> The patch is way to big to attach here, but are there any comments
> before I commit to trunk?
For anyone else who's curious, I had Cody send me a copy you could
look over here:
http://users.ices.utexas.edu/~roystgnr/0001-Fparser-Update.patch
No obviou
On Sun, Mar 25, 2012 at 2:26 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> Paul, can you check the recent fparser additions with GCC 4.7 and 4.6 using
> libmesh.automake?
>
libmesh.automake branch r5431 is building successfully for me with both GCC
4.6.3 and GCC 4.7.0.
-
On Tue, 27 Mar 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Thanks - is that a ubuntu provided PETSC?
Yes.
> I'm guessing it doesn't have a makefile installed and a fix in
> petsc.m4 will do the trick.
Looks like it does have rules, petscrules and petscvariables files in
/usr/lib/petscdir/{3.0.0,
...and with an LTS version release in a month or so I'll probably jump straight
to ubuntu 12.04 LTS beta and work there. I expect the same or more issues!
On Mar 27, 2012, at 7:02 AM, "Kirk, Benjamin (JSC-EG311)"
wrote:
> Thanks - is that a ubuntu provided PETSC? I'm guessing it doesn't ha
Thanks - is that a ubuntu provided PETSC? I'm guessing it doesn't have a
makefile installed and a fix in petsc.m4 will do the trick.
I'll see about installing a fresh ubuntu box and work it out.
-Ben
On Mar 26, 2012, at 11:51 PM, "Roy Stogner" wrote:
>
> On Sun, 25 Mar 2012, Kirk, Benja
On Sun, 25 Mar 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Also, Roy, I ported the clang support you added but don't have a machine to
> test it on. Could you see if the branch will build when you get a chance?
I couldn't even get the branch to build *without* clang, once I tried
it for the first
Thanks. Probably related.
I just finished (I think) porting the fparser stuff the libmesh.automake
branch. The build for that thing is *tricky*, and I'm not sure we are doing
it right in trunk because there are three autogenerated files, I think we
are handling 1?
Clearly the "extrasrc/fp_opcod
>
> Indeed. r5396 builds fine on my laptop. Most of the libraries are there on
> ICES machines now, but haven't built libMesh yet.
>
I don't know if this is related but trying build with gcc 4.6, I get
following errors:
Creating Bytecode (in debug mode) util/bytecoderules_parser...
Compiling C++
On Sun, Mar 25, 2012 at 1:56 AM, Roy Stogner wrote:
> Give the svn head a try when you're done? I fixed all the errors and
> many of the warnings that clang on Ubuntu 11.10 gave me; hopefully the
> fixes carry over to gcc 4.7.0 as well.
>
Indeed. r5396 builds fine on my laptop. Most of the libra
On Sat, 24 Mar 2012, Paul T. Bauman wrote:
On Sat, Mar 24, 2012 at 3:38 PM, Roy Stogner wrote:
Are we giggling on the ICES filesystems with a new gcc 4.7.0 module, by
any chance?
This is on my laptop, but I'll get these modules going on ICES. Shouldn't be
more than a few hours.
On Sat, Mar 24, 2012 at 3:38 PM, Roy Stogner wrote:
> Are we giggling on the ICES filesystems with a new gcc 4.7.0 module, by
> any chance?
This is on my laptop, but I'll get these modules going on ICES. Shouldn't
be more than a few hours.
On Sat, 24 Mar 2012, Paul T. Bauman wrote:
> I thought I'd post this for those living on the edge of compilers. I
> was trying out gcc 4.7.0 for giggles
Are we giggling on the ICES filesystems with a new gcc 4.7.0 module, by
any chance? I'd definitely want to get us clang and gcc 4.7
compatible
Moving it outside of trunk is fine with us. I don't think any of the MOOSE
guys grab the entire repository.
If you want to speed the time to fork just have Derek get in a debate with
the author of the code over "military uses" or something...
Cody
On Thu, Feb 23, 2012 at 9:47 AM, Roy Stogner wr
Could we just move them out of trunk/ so most people don't download
them? We won't ever need them unless we have to fork fparser someday,
but it's not like that would be the first time we'd had to fork a
third-party contribution...
---
Roy
On Thu, 23 Feb 2012, Derek Gaston wrote:
> Kill Kill Ki
Kill Kill Kill
On Feb 23, 2012, at 8:40 AM, Cody Permann wrote:
> So I did a file count on libMesh the other day. Prior to add fparser to
> contrib the size of the library was 1860 files give or take. After adding
> fparser the size of the library has ballooned to over 2900 files. It turns
I just checked in an updated Makefile for fparser. It appears to work
properly now with parallel make on our Linux and Mac systems.
Cody
On Tue, Feb 21, 2012 at 7:23 PM, Derek Gaston wrote:
> Or maybe do it now... it might fix the problem ;-)
>
> For the record we always just used a straight l
Or maybe do it now... it might fix the problem ;-)
For the record we always just used a straight libMesh contrib style
Makefile to build FParser in MOOSE. We junked their stuff almost
immediately...
Derek
On Tue, Feb 21, 2012 at 7:21 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wr
Good work. I've spent a good bit of the day wrapping all the other contributed
sources with automake - ill probably hold off on this one until last.
-Ben
On Feb 21, 2012, at 5:41 PM, "Cody Permann"
mailto:codyperm...@gmail.com>> wrote:
I finally figured out the why "fparser" is crashing on o
I finally figured out the why "fparser" is crashing on our Linux machines.
It's been maddening, tracking this bug down since the behavior only
manifested itself in certain situations and in optimized mode only. It was
a "Heisenbug" since any attempt to observe the bug would modify it's
behavior.
On Fri, Feb 10, 2012 at 3:54 PM, Roy Stogner wrote:
>
> On Tue, 7 Feb 2012, Roy Stogner wrote:
>
> > On Mon, 6 Feb 2012, Roy Stogner wrote:
> >
> >> On Mon, 6 Feb 2012, Kirk, Benjamin (JSC-EG311) wrote:
> >>
> >>> Anyone got a snippet showing how to use the contributed fparser?
> >>>
> >>> We'd lo
On Tue, 7 Feb 2012, Roy Stogner wrote:
> On Mon, 6 Feb 2012, Roy Stogner wrote:
>
>> On Mon, 6 Feb 2012, Kirk, Benjamin (JSC-EG311) wrote:
>>
>>> Anyone got a snippet showing how to use the contributed fparser?
>>>
>>> We'd love to add that capability to some application code here...
>>
>> I'm
On Tue, 7 Feb 2012, Roy Stogner wrote:
> Anyone have preferences as to whether this method should be pure
> virtual (breaking backwards compatibility for users with
> FunctionBase subclasses) or have a libmesh_not_implemented() default
> (causing runtime breakage when users pass their FunctionBas
On Mon, 6 Feb 2012, Roy Stogner wrote:
>
> On Mon, 6 Feb 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> Anyone got a snippet showing how to use the contributed fparser?
>>
>> We'd love to add that capability to some application code here...
>
> I'm going to put it into an example, but probably no
On Mon, Feb 6, 2012 at 11:05 AM, Roy Stogner wrote:
>
> On Mon, 6 Feb 2012, Cody Permann wrote:
>
> If you have any questions or would like to see our "ParsedFunction"
>> wrapper class let me know.
>>
>
> You know, I specifically remember thinking while picking a generic
> obvious class name that
On Mon, 6 Feb 2012, Cody Permann wrote:
> If you have any questions or would like to see our "ParsedFunction" wrapper
> class let me know.
You know, I specifically remember thinking while picking a generic
obvious class name that this might be a problem, but I should have
asked in advance:
Any
Hey Ben,
I just looked out our wrapper class around fparser and it's got a lot of
extra stuff in it so it's not all that useful as a quick example here. The
documentation is actually pretty good on their website and right near the
top they have a 4 line example that shows you how to get started:
On Mon, 6 Feb 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Anyone got a snippet showing how to use the contributed fparser?
>
> We'd love to add that capability to some application code here...
I'm going to put it into an example, but probably not until after the
System::project_vector changes are
On Mon, 30 Jan 2012, Derek Gaston wrote:
Let me say this though: it doesn't need the optimizer stuff. I was
just running benchmarks last night that heavily utilized FParser…
and it doesn't even show up in profiling… like not even close. I
propose just turning it off for now (or maybe just tur
That's possibly it. I remember that getting commented out myself… and it was
definitely for a compile issue, but I can't remember if it was exactly this
issue.
Let me say this though: it doesn't need the optimizer stuff. I was just
running benchmarks last night that heavily utilized FParser…
On Mon, Jan 30, 2012 at 2:59 PM, Derek Gaston wrote:
> What's weird to me is that we have fparser working fine in MOOSE. What's
> different about our version? Is this something that Phillip (the intern who
> put in the function parsing stuff) solved when he put fparser into MOOSE or
> is this
What's weird to me is that we have fparser working fine in MOOSE. What's
different about our version? Is this something that Phillip (the intern who
put in the function parsing stuff) solved when he put fparser into MOOSE or is
this something that has happened in the interim?
Derek
On Jan 30
> I'm pretty sure multiple instantiations in different translation units
> are allowed by the standard... the linker should be able to sort them
> out.
>
> Is that not the case?
Thought so, then again isn't this the debacle that has helped get 'extern'
into the new standard for template instantia
On Mon, 30 Jan 2012, John Peterson wrote:
> I'm pretty sure multiple instantiations in different translation units
> are allowed by the standard... the linker should be able to sort them
> out.
I believe so. Otherwise everybody's code would break as soon as they
tried to do a vector v; no?
Wh
On Mon, Jan 30, 2012 at 10:52 AM, John Peterson wrote:
>
> Anyway, I think we've at least tracked the issue down to the macro
>
> FUNCTIONPARSER_INSTANTIATE_TYPES
>
> which appears in both fparser.cc and fpoptimizer/optimize_main.cc. If
> I comment out the macro from one of those files, fparser s
On Mon, Jan 30, 2012 at 9:27 AM, Roy Stogner wrote:
>
>> .) We're getting the following linker error:
>>
>> Linking
>> .../libmesh_git/contrib/lib/x86_64-apple-darwin10.8.0_opt/libfparser.dylib
>> ld: duplicate symbol
>> FunctionParserBase::FunctionWrapper::FunctionWrapper()in
>> fpoptimizer/optim
On Mon, 30 Jan 2012, John Peterson wrote:
> There are a couple of issues with the fparser stuff on Mac OSX...
I was afraid something might crop up; I'd copied and pasted some of
the special-case OSX code from another contrib Makefile but I'd only
tested on Linux before committing.
Apologies to
40 matches
Mail list logo
