Stan unit tests working on jenkins

[Daniel Lee]

Bob, I think you fixed the issues g++ was having with the parser test. We'll talk tomorrow or at the meeting.

Daniel

[Ben Goodrich]

I'm not seeing all that much progress. With g++-4.7 the same tests are failing. With clang-3.2, it is now failing to link

clang++ -I src -I lib/eigen_3.1.2 -I /usr/include -O3 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -Wno-unused-function -Wno-uninitialized   -c -std=c++0x -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0 -I lib/gtest_1.6.0/include -I lib/gtest_1.6.0 src/test/gm/parser_test.cpp -o test/gm/parser.o
ar -rs bin/libstanc.a bin/stan/gm/grammars/expression_grammar_inst.o bin/stan/gm/grammars/whitespace_grammar_inst.o bin/stan/gm/grammars/program_grammar_inst.o bin/stan/gm/grammars/statement_grammar_inst.o bin/stan/gm/grammars/var_decls_grammar_inst.o bin/stan/gm/grammars/term_grammar_inst.o bin/stan/gm/grammars/statement_2_grammar_inst.o bin/stan/gm/ast_def.o
ar: creating bin/libstanc.a
clang++ -I src -I lib/eigen_3.1.2 -I /usr/include -O3 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -Wno-unused-function -Wno-uninitialized    lib/gtest_1.6.0/src/gtest_main.cc test/gm/parser.o -std=c++0x -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0 -I lib/gtest_1.6.0/include -I lib/gtest_1.6.0 -o test/gm/parser test/libgtest.a -Lbin -lstan -Lbin -lstanc
test/gm/parser.o: In function `stan::gm::statement_grammar<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char, std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted, boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator, boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::statement_grammar(stan::gm::variable_map&, std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&)':
src/test/gm/parser_test.cpp:(.text._ZN4stan2gm17statement_grammarIN5boost6spirit7classic18position_iterator2INS3_10multi_passINSt3__119istreambuf_iteratorIcNS7_11char_traitsIcEEEENS3_17iterator_policies14default_policyINSC_11ref_countedENSC_8no_checkENSC_24buffering_input_iteratorENSC_15split_std_dequeEEEEENS4_18file_position_baseINS7_12basic_stringIcSA_NS7_9allocatorIcEEEEEEEEEC2ERNS0_12variable_mapERNS7_18basic_stringstreamIcSA_SN_EE[_ZN4stan2gm17statement_grammarIN5boost6spirit7classic18position_iterator2INS3_10multi_passINSt3__119istreambuf_iteratorIcNS7_11char_traitsIcEEEENS3_17iterator_policies14default_policyINSC_11ref_countedENSC_8no_checkENSC_24buffering_input_iteratorENSC_15split_std_dequeEEEEENS4_18file_position_baseINS7_12basic_stringIcSA_NS7_9allocatorIcEEEEEEEEEC2ERNS0_12variable_mapERNS7_18basic_stringstreamIcSA_SN_EE]+0xb8): undefined reference to `stan::gm::statement_2_grammar<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char, std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted, boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator, boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::statement_2_grammar(stan::gm::variable_map&, std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, stan::gm::statement_grammar<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char, std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted, boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator, boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >&)'
test/gm/parser.o: In function `stan::gm::expression_grammar<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char, std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted, boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator, boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::expression_grammar(stan::gm::variable_map&, std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, bool)':
src/test/gm/parser_test.cpp:(.text._ZN4stan2gm18expression_grammarIN5boost6spirit7classic18position_iterator2INS3_10multi_passINSt3__119istreambuf_iteratorIcNS7_11char_traitsIcEEEENS3_17iterator_policies14default_policyINSC_11ref_countedENSC_8no_checkENSC_24buffering_input_iteratorENSC_15split_std_dequeEEEEENS4_18file_position_baseINS7_12basic_stringIcSA_NS7_9allocatorIcEEEEEEEEEC2ERNS0_12variable_mapERNS7_18basic_stringstreamIcSA_SN_EEb[_ZN4stan2gm18expression_grammarIN5boost6spirit7classic18position_iterator2INS3_10multi_passINSt3__119istreambuf_iteratorIcNS7_11char_traitsIcEEEENS3_17iterator_policies14default_policyINSC_11ref_countedENSC_8no_checkENSC_24buffering_input_iteratorENSC_15split_std_dequeEEEEENS4_18file_position_baseINS7_12basic_stringIcSA_NS7_9allocatorIcEEEEEEEEEC2ERNS0_12variable_mapERNS7_18basic_stringstreamIcSA_SN_EEb]+0x8d): undefined reference to `stan::gm::term_grammar<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char, std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted, boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator, boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::term_grammar(stan::gm::variable_map&, std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, stan::gm::expression_grammar<boost::spirit::classic::position_iterator2<boost::spirit::multi_pass<std::__1::istreambuf_iterator<char, std::__1::char_traits<char> >, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted, boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::buffering_input_iterator, boost::spirit::iterator_policies::split_std_deque> >, boost::spirit::classic::file_position_base<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >&)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [test/gm/parser] Error 1
goodrich@CYBERPOWERPC:/opt/stan$

What make/os_mac are you working with?

Ben

[Bob Carpenter]

On 12/9/12 3:41 PM, Daniel Lee wrote:
> Bob, I think you fixed the issues g++ was having with the parser test. We'll talk tomorrow or at the meeting.

I broke the parser down into smaller translation units.
It was a bit of pain, but totally do-able. I hadn't even
tried before because I thought the problem with Jenkins
was related to C++11.

I still think we can do a release without full C++11
compatibility.

My next priority is going to be tracking down the C++11
issues.

- Bob

[Ben Goodrich]

On Sunday, December 9, 2012 5:21:42 PM UTC-5, Ben Goodrich wrote:

I'm not seeing all that much progress. With g++-4.7 the same tests are failing. With clang-3.2, it is now failing to link

To clarify, that linker error is with applying the c++0x to gtest only. If the c++0x is applied to everything via

CFLAGS += -std=c++0x
CFLAGS += -stdlib=libc++

then there is a different linking error

clang++ -I src -I lib/eigen_3.1.2 -I lib/boost_1.52.0 -O3 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -std=c++0x -stdlib=libc++ -Wno-unused-function -Wno-uninitialized    lib/gtest_1.6.0/src/gtest_main.cc test/gm/parser.o -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0 -I lib/gtest_1.6.0/include -I lib/gtest_1.6.0 -o test/gm/parser test/libgtest.a -Lbin -lstan -Lbin -lstanc
bin/libstanc.a(expression_grammar_inst.o):(.bss+0x2): multiple definition of `stan::gm::binary_op_f'
test/gm/parser.o:(.bss+0xc): first defined here
bin/libstanc.a(expression_grammar_inst.o):(.bss+0x4): multiple definition of `stan::gm::subtraction'
test/gm/parser.o:(.bss+0xe): first defined here
bin/libstanc.a(expression_grammar_inst.o):(.bss+0x1): multiple definition of `stan::gm::set_fun_type2_f'
test/gm/parser.o:(.bss+0xb): first defined here
bin/libstanc.a(expression_grammar_inst.o):(.bss+0x0): multiple definition of `stan::gm::validate_expr_type2_f'
test/gm/parser.o:(.bss+0xa): first defined here
bin/libstanc.a(expression_grammar_inst.o):(.bss+0x3): multiple definition of `stan::gm::addition'
test/gm/parser.o:(.bss+0xd): first defined here

clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [test/gm/parser] Error 1

Ben

[Bob Carpenter]

Here's what I'd like to do:

Goal 1: Release Stan 1.0.4 ASAP to fix bugs. The compatibility
goal is whatever we had in 1.0.3 and no more.

Goal 2: Organize the code so it'll work with C++11
and also work without C++11 (including testing w/o C++11).

OR

Require C++11 and use C++11 features.

OR

Don't use C++11 and worry about it later.

This brings up some questions:

Question 1: If we just turn off all the C++11 features,
is Stan passing tests on all the platforms it passed tests
for in version 1.0.3?

Question 2: How much work do we need to do to back out any
C++11 dependencies in the new test code?

Question 3: Is there some reason (perhaps having to do with
R, availability on the Mac or Windows, etc) that we can't move
to always building everything with C++11 flags?

Question 4: What versions of clang++ and g++ under what
backend configs do we need to support?

I just realized it's risky to try to test under C++11 and
run under no C++11. I'd rather test the same thing we run.

For the record, as of right now, I can run:

Platform:
Mac OS X 10.8.2
Compiler:
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Linker:
Not even sure what the default is here now that I know
there are so many ways it can be configured front and back and lib
CFLAGS:
?? (I'm running the defaults, but looking at output of "make test-unit", they seem to vary)
-DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -Wno-unused-function -Wno-tautological-compare
?? in building gtest, I also see -std=c++0x and then:
c1plus: error: unrecognized command line option "-std=c++0x"
CFLAGS_GTEST:
?? (same issue as above -- not sure where the GTEST ones apply)
CFLAGS + -Wno-c++11-extensions
Stan Version:
commit 094ad9f9e91384f9882715406398513d5ca73d7b
Date:
10 Dec 2012
test-unit:
pass

I haven't figured out a magic set of C++11 flags to let me
compile with g++ on the same platform.

- Bob

[Ben Goodrich]

On Monday, December 10, 2012 12:46:15 AM UTC-5, Bob Carpenter wrote:

This brings up some questions:

   Question 1:  If we just turn off all the C++11 features,
   is Stan passing tests on all the platforms it passed tests
   for in version 1.0.3?

At the moment, there are default template parameters (and maybe some other C++11 features, not sure) in some of the tests. If we didn't specify -std=c++0x AND reverted the commits that used C++11 features, I speculate that all the tests would pass. But I think that would be overkill. AFAIK, the only test that is not passing (in some setups) is src/test/gm/parser_test.cpp, which doesn't use any C++11 specific features (that I can see) but doesn't play nice with the intersection of boost and "recent" compilers when -std=c++0x is added to CFLAGS_GTEST (or CFLAGS for that matter).

But that test is somewhat of a luxury because stanc parses everything as long as CFLAGS does not add -std=c++0x. That is why I was proposing restricting the -std=c++0x stuff to CFLAGS_GTEST, blacklisting src/test/gm/parser_test.cpp, doing v1.0.4, and then coming back to it.

   Question 2:  How much work do we need to do to back out any
   C++11 dependencies in the new test code?

Not that much, but I don't think it is necessary to back them out. Even if you wanted to do a release with src/test/gm/parser_test.cpp passing, you could just branch from something before 4377102d597c9bd5f011136ea21e6e995c84ac4d. The problem is that you would loose a lot of good commits since then.

   Question 3:  Is there some reason (perhaps having to do with
   R, availability on the Mac or Windows, etc) that we can't move
   to always building everything with C++11 flags?

CRAN has discouraging things to say about it

http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Submitting-a-package-to-CRAN

but I am not sure it is prohibited on CRAN. I think g++-4.6 (and the corresponding mingw) just ignores the -std=c++0x thing, but it does implement some features that were later ratified into the C++11 standard. You can see a comparison of compilers here

https://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

My understanding is that the squeekiest wheel is the g++ that comes with Xcode, but I don't really know what to expect from that. We know that the standard C++ library that comes with g++-4.2.x is too old to support any C++11 features (leading to the problem with std::forward that you ran into Friday) but if you use LLVM's C++ library, clang works. So, I don't know what happens if you use the Mac hybrid of LLVM for the first pass and g++-4.2 to finish it with LLVM's C++ library.

But the main thing at the moment is that if you use --std=c++0x to build stanc, then no .stan file parses correctly, but that is independent of R and CRAN.

   Question 4:  What versions of clang++ and g++ under what
   backend configs do we need to support?

I'd say the only things we have to support are the compilers on the CRAN servers

http://cran.r-project.org/web/checks/check_flavors.html#r-devel-linux-x86_64-debian

even if RStan never goes onto CRAN. If RStan were to go onto CRAN in some form, then I believe you are only allowed to fail one compiler. Of those, Solaris Studio is already out because it doesn't do boost, eigen, or C++11. GCC 4.6.3 has always been passing on Linux and seems to be passing on Jenkins ATM. GCC 4.7.2 only fails the blacklistable src/test/gm/parser_test.cpp under -std=c++0x.

Clang isn't strictly necessary. But recent versions are the best compilers for Stan, so I think we should be encouraging people to use clang++ rather than contemplating regressions here. Clang isn't systematically slower in runtime, is much better in terms of RAM consumption, compile time, and availability of extra tools, and is a bit better in terms of error messages and completeness of C++11 implementation. Up until today, clang++-3.1 and clang-3.2++ RC had the same test failure as 4.7.2; now they have linker errors rather than test failures with blacklistable src/test/gm/parser_test.cpp.
 

I just realized it's risky to try to test under C++11 and
run under no C++11.  I'd rather test the same thing we run.

Agreed it would be ideal if it were possible to get everything working with CFLAGS += -std=c++0x, but also working with merely CFLAGS_GTEST += -std=c++0x. For a release and / or CRAN, we could turn off CFLAGS += -std=c++0x and turn on CFLAGS_GTEST += -std=c++0x if necessary.

For the record, as of right now, I can run:

   Platform:
      Mac OS X 10.8.2
   Compiler:
      Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
   Linker:
      Not even sure what the default is here now that I know
      there are so many ways it can be configured front and back and lib
   CFLAGS:
      ?? (I'm running the defaults, but looking at output of "make test-unit", they seem to vary)
      -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -Wno-unused-function -Wno-tautological-compare
      ?? in building gtest, I also see -std=c++0x and then:
            c1plus: error: unrecognized command line option "-std=c++0x"
   CFLAGS_GTEST:
      ?? (same issue as above -- not sure where the GTEST ones apply)

Look in make/tests, but basically if in make/os_* it says CFLAGS_GTEST += -std=c++0x but not CFLAGS += -std=c++0x, then libstan, stanc, libstanc, etc. implicitly reference -std=g++98 while the tests built by test-unit and test-models explicitly reference -std=c++0x. That would be a decent state of affairs, except that the blacklistable src/test/gm/parser_test.cpp fails for g++-4.7.x and my versions of clang++-3.1 and clang++-3.2.

I haven't figured out a magic set of C++11 flags to let me
compile with g++ on the same platform.

My guess is that many of the tests in test-unit will currently fail with g++-4.2.x if it uses the associated standard C++ library due to complete lack of any C++11 stuff. The thing to try is CFLAGS_GTEST += -stdlib=libc++ (and maybe CFLAGS += -stdlib=libc++), which uses LLVM's standard C++ library (and hopefully is included in Xcode; if not you can download it from llvm.org).

Ben

[Ben Goodrich]

Maybe the attachment will be helpful? It is the output from subjecting src/test/gm/parser_test.cpp to

https://github.com/drothlis/clang-ctags

which uses clang-3.2 to generate an Emacs compatible "tags" file, which is sort of like an index of index of all mentioned functions in a .cpp / .hpp file or set of files. See

http://emacswiki.org/emacs/EmacsTags

Anyway, if you just open it in a text editor, you can see where all the functions came from and why there seem to be multiple definitions in some cases.

Ben

[Ben Goodrich]

On Sunday, December 9, 2012 5:21:42 PM UTC-5, Ben Goodrich wrote:

I'm not seeing all that much progress. With g++-4.7 the same tests are failing. With clang-3.2, it is now failing to link

Or maybe these attachments will be helpful? When g++-4.7 is used (leading to test failures), the binary for test/gm/parser is almost 50% bigger than the binary when g++-4.6 (which passes) presumably due to the former trying to honor CFLAGS_GTEST += -std=c++0x. I pulled out the strings from each with

goodrich@CYBERPOWERPC:/tmp$ strings parser_4.6 | sort | uniq > strings_parser_4.6.txt
goodrich@CYBERPOWERPC:/tmp$ strings parser_4.7 | sort | uniq > strings_parser_4.7.txt

If you look at them with some side-by-side diff GUI, then you might be able to get somewhere. There is a lot of string noise, but presumably the things that mention boost are the most relevant to the problem we are facing.

Ben

[Ben Goodrich]

 
That was with O=3. It is much better to use the attached files, which were made from the binaries with O=0. That test passes for g++-4.6 and fails for g++-4.7 regardless of the level of optimization, but the strings have much less junk when O=0.

Ben

[Ben Goodrich]

On Sunday, December 9, 2012 9:48:14 PM UTC-5, Ben Goodrich wrote:

On Sunday, December 9, 2012 5:21:42 PM UTC-5, Ben Goodrich wrote:

I'm not seeing all that much progress. With g++-4.7 the same tests are failing. With clang-3.2, it is now failing to link

To clarify, that linker error is with applying the c++0x to gtest only. If the c++0x is applied to everything via

CFLAGS += -std=c++0x
CFLAGS += -stdlib=libc++

then there is a different linking error

But only with optimization. When O=0, test-unit passes for clang++-3.2.

Ben

[Ben Goodrich]

And with O=1, test-unit compiles but the parser test fails like it does for g++-4.7.x. With O >= 2, there is the linking error. However, in all cases, there are a bunch of parser-related warnings about returning references to local temporary object and so forth.

Ben

[Ben Goodrich]

 
OK, now I am one step closer. Possibly to the edge; possibly to a solution. The attachment is a zip archive of a git-ified directory with one file called strings_parser.txt. There are two tagged commits, g++-4.6 and g++-4.7, depending on which compiler made test/gm/parser before pulling out the unique strings. Again, that test passes under g++-4.6 and fails under g++-4.7.

Unzip that directory, go into it, and do

git diff --word-diff=color g++-4.6 g++-4.7

to see the colorized string differences in a pager. It appears as if, for a number of strings, that

boost::* [with T = boost::recursive_wrapper<stan::gm::array_literal>, boost::*

becomes

boost::* [with T = boost::recursive_wrapper<stan::gm::array_literal>; boost::*

i.e. the comma becomes a semi-colon. And the same ", -> ;" thing happens in several other places. There are also a couple of other new lines and whatnot. Thus, the question becomes: WTF?

Ben

[Ben Goodrich]

The other two suspicious changes are that g++-4.7 adds a new

bool boost::spirit::qi::error_handler

and this thing

static typename MultiPass ...

that ends with

... typename MultiPass::reference = char&]

on  g++-4.6 while g++-4.7 has a variant that ends with char& and a variant that ends with char (see lines 1336 and 1337 of the earlier strings_parser_4.7.txt).

Ben

[Bob Carpenter]

I think the problem with the parser test was that
the includes were for the _def.hpp with the definitions
rather than just the headers in the .hpp files.

The size issues were probably due to the double definitions.

The current makefile does NOT use any c++11 features
for g++ or clang++ in the os_mac config. For clang++,
Daniel even included warnings for c++11 extensions.

With the current makefile, tests pass for me on
Mac OS X Lion, with latest Xcode versions of g++
and clang++ at -O0 and -O3 optimization:

~/stan>clang++ --version

Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)

~/stan>g++ --version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

Before the change they passed with g++ -O0, but not g++ -O3.
I'm not sure why it would've worked with -O0 given the double definitions.

I'm wondering if the ';' vs ',' in the strings output is
just a change in arbitrary convention rather than something
important.

I'll try to install clang++ 3.2 and g++ 4.7 version and see if I can
get it working.

- Bob

> --
>
>

[Ben Goodrich]

On Friday, December 14, 2012 3:08:55 AM UTC-5, Bob Carpenter wrote:

I think the problem with the parser test was that
the includes were for the _def.hpp with the definitions
rather than just the headers in the .hpp files.

Yep.
 

The size issues were probably due to the double definitions.

I can cross-compile for Windows with O=0 now, which if the same holds for Jenkins, suggests that we can revisit the idea of using no optimization to compile stanc. Optimization of stanc expends a lot of RAM for no discernible benefit to users, as opposed to libstan where it actually makes a difference for users' models.
 

The current makefile does NOT use any c++11 features
for g++ or clang++ in the os_mac config.  For clang++,
Daniel even included warnings for c++11 extensions.

True, although now I am thinking that maybe there wasn't any problem with c++11 per se, just a wider variety of weird behavior for a buggy parser_test.cpp.
 

With the current makefile, tests pass for me on
Mac OS X Lion, with latest Xcode versions of g++
and clang++ at -O0 and -O3 optimization:

~/stan>clang++ --version
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)

~/stan>g++ --version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

Before the change they passed with g++ -O0, but not g++ -O3.
I'm not sure why it would've worked with -O0 given the double definitions.

Can we try to remember to update

https://code.google.com/p/stan/wiki/TestUnitStatus?ts=1355477713&updated=TestUnitStatus

whenever there is progress or regress for test-unit that doesn't involve Jenkins?

I'm wondering if the ';' vs ',' in the strings output is
just a change in arbitrary convention rather than something
important.

Probably.
 

I'll try to install clang++ 3.2 and g++ 4.7 version and see if I can
get it working.

With a recent clang and

CFLAGS += -stdlib=libc++ -std=c++98

I still have parser failures and weird boost warnings, although everything compiles. Note that the above uses the LLVM version of the standard C++ library (as opposed to GCC's), which is allegedly c++11 compliant, but can also be used with the old standard.

Ben

[Jiqiang Guo]

With a recent clang and

Th

CFLAGS += -stdlib=libc++ -std=c++98


I still have parser failures and weird boost warnings, although everything compiles. Note that the above uses the LLVM version of the standard C++ library (as opposed to GCC's), which is allegedly c++11 compliant, but can also be used with the old standard.

It is compliant on Mac, not on Linux. See problem with Linux at http://libcxx.llvm.org/results.Linux.html

Jiqiang

[Ben Goodrich]

Right, it is not as far along on Linux / Windows as Mac. I actually had run the libcxx test suite yesterday and got a few more errors, but none that looked similar to what I had been seeing from Stan / boost (which was similar to what we saw with g++ >= 4.7 with -std=c++0x). But has anyone even tried test-unit on a Mac with  CFLAGS += -stdlib=libc++ -std=c++98? If that works, then I think it is fine if we just document that Linux currently requires GCC's version of the standard C++ library.

Ben

[Bob Carpenter]

On 12/14/12 4:44 AM, Ben Goodrich wrote:
> ... we can revisit the idea

> of using no optimization to compile stanc. Optimization of stanc expends a lot of RAM for no discernible benefit to
> users, as opposed to libstan where it actually makes a difference for users' models.

Compiling stanc with -O0 seems the right thing
to do.

> Can we try to remember to update
>
> https://code.google.com/p/stan/wiki/TestUnitStatus?ts=1355477713&updated=TestUnitStatus
>
> whenever there is progress or regress for test-unit that doesn't involve Jenkins?

I didn't realize it was there. I'll try to keep it up to date
for things I test until we come up with a more automated approach.

Given the enormous problems we've had (and are still having) with
1.0.4, I think we need to (1) decide on which tests we really care
about, and (2) automate the running of all the tests we want to run.

I have to say that I'm still completely overwhelmed by the
combinatorics of the compilation portability problem, which
presents us with at least the following set of knobs to twiddle:

- Platform (Windows, Mac, Linux)
- Version of platform (only latest?)
- compiler (c++, g++, llvm-g++, mingw32, icpc)
- compiler version
- optimization level (0, 1, 2, 3)
- c++ version (default, c++11, c++99)
- library version (???)

The table we're trying to update should have hundreds of
rows if we want to handle all combinations.

> ... now I am thinking that maybe there wasn't any problem with c++11 per se, just a wider variety of weird

> behavior for a buggy parser_test.cpp.

That would be a nice outcome! It's the next thing I'll look
at if I can manage to get things running. I ran homebrew, but
after this, I have to go on a hunt to find where it was installed
and what the compiler's called.

> With a recent clang and
>
> |
> CFLAGS += -stdlib=libc++ -std=c++98

What does -std=c++98 do? Is it the default case if
no std value is supplied? I can't even find the doc for it --
it's not given in --help. I'm seeing references to bug reports
for when it's turned on from ages ago, but nothing very recent.

I'm also seeing references to c++03, whatever that is.

> I still have parser failures and weird boost warnings, although everything compiles. Note that the above uses the LLVM
> version of the standard C++ library (as opposed to GCC's), which is allegedly c++11 compliant, but can also be used with
> the old standard.

I can't figure out whether

According to this:

http://clang.llvm.org/cxx_status.html

"Patches are also needed to make libstdc++-4.6, and libstdc++-4.7 work
with Clang releases prior to version 3.2 in C++11 mode."

- Bob

[Bob Carpenter]

On 12/14/12 12:46 PM, Ben Goodrich wrote:
> On Friday, December 14, 2012 10:23:46 AM UTC-5, Jiqiang Guo wrote:
>
>
> With a recent clang and
> Th
> |CFLAGS += -stdlib=libc++ -std=c++98
> |
>
> I still have parser failures and weird boost warnings, although everything compiles. Note that the above uses
> the LLVM version of the standard C++ library (as opposed to GCC's), which is allegedly c++11 compliant, but can
> also be used with the old standard.
>
> It is compliant on Mac, not on Linux. See problem with Linux at http://libcxx.llvm.org/results.Linux.html
> <http://libcxx.llvm.org/results.Linux.html>
>
>
> Right, it is not as far along on Linux / Windows as Mac. I actually had run the libcxx test suite yesterday and got a
> few more errors, but none that looked similar to what I had been seeing from Stan / boost (which was similar to what we
> saw with g++ >= 4.7 with -std=c++0x). But has anyone even tried test-unit on a Mac with

> |CFLAGS += -stdlib=libc++ -std=c++98|? If that works, then I think it is fine if we just document that Linux currently

> requires GCC's version of the standard C++ library.

No, it doesn't work, but at least this one's clearly
not our fault -- it's missing a lib that gtest includes:

OS X clang++ 3.1 -O0 -stdlib=libc++ -std=c++98
-------------------------------------------------
clang++ -I src -I lib/eigen_3.1.2 -I lib/boost_1.52.0 -O0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE
-Wno-unused-function -Wno-tautological-compare -stdlib=libc++ -std=c++98 -c -Wc++11-extensions -I
lib/gtest_1.6.0/include -I lib/gtest_1.6.0 lib/gtest_1.6.0/src/gtest-all.cc -o test/gtest.o
In file included from lib/gtest_1.6.0/src/gtest-all.cc:39:
In file included from lib/gtest_1.6.0/include/gtest/gtest.h:57:
In file included from lib/gtest_1.6.0/include/gtest/internal/gtest-internal.h:40:
lib/gtest_1.6.0/include/gtest/internal/gtest-port.h:499:13: fatal error: 'tr1/tuple' file not found
# include <tr1/tuple> // NOLINT
^
1 error generated.
---------------------------------------------------

If I remove the libc++, the tests pass.

The tests fail with c++11, but I think that's an issue with
Eigen or with the libs, because Eigen's using a lib that's not there.

OS X clang++ 3.1 -O0 -std=c++11
-------------------------------------------
lang++ -I src -I lib/eigen_3.1.2 -I lib/boost_1.52.0 -O0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE
-Wno-unused-function -Wno-tautological-compare -std=c++11 -c -o bin/stan/agrad/agrad.o src/stan/agrad/agrad.cpp
In file included from src/stan/math/matrix.cpp:4:
In file included from src/stan/math/matrix.hpp:12:
In file included from lib/eigen_3.1.2/Eigen/Dense:1:
In file included from lib/eigen_3.1.2/Eigen/Core:248:
lib/eigen_3.1.2/Eigen/src/Core/util/Memory.h:713:23: error: no member named 'forward' in namespace 'std'
::new(p) T(std::forward<Args>(args)...);
~~~~~^
lib/eigen_3.1.2/Eigen/src/Core/util/Memory.h:713:31: error: 'Args' does not refer to a value
::new(p) T(std::forward<Args>(args)...);
^
lib/eigen_3.1.2/Eigen/src/Core/util/Memory.h:710:26: note: declared here
template<typename... Args>
----------------------------------------


And with the -stdlib=libc++, a two errors for your amusement, one
in gtest and one in the parser:

OS X clang++ 3.1 -O0 -stdlib=libc++ -std=c++11
--------------------------------------
In file included from lib/gtest_1.6.0/include/gtest/internal/gtest-internal.h:40:
lib/gtest_1.6.0/include/gtest/internal/gtest-port.h:499:13: fatal error: 'tr1/tuple' file not found
# include <tr1/tuple> // NOLINT

.....


In file included from lib/boost_1.52.0/boost/iterator/reverse_iterator.hpp:12:
lib/boost_1.52.0/boost/iterator/iterator_adaptor.hpp:306:18: warning: returning reference to local temporary object
[-Wreturn-stack-address]
{ return *m_iterator; }
---------------------------------------

That latter issue also doesn't look like our fault, as we didn't
write the function which is returning a ref to a local temporary.

I also added the above to the wiki.

- Bob

[Marcus Brubaker]

This won't really help in the short term, but I have an 8 core machine that is sitting relatively idle right now.  I could repurpose it to a LInux buildbot with Jenkins.  I've not set Jenkins up before, but if someone gave me a few pointers and maybe send along the Stan-specific configuration being used I'm sure if wouldn't be too hard.  Just a thought.

As to the various standards/libs/etc I would suggest we pick a small number of reasonable platform targets with the goal being to build using only the easily available compilers/libs on those platforms.  For instance, on Linux, I would suggest we target GCC and LLVM on the latest version of a RHEL-like distribution and the latest version of Ubuntu.  Together they cover most Linux systems likely to be seen in practice.  Trying to support all possible combinations leads to madness and as enticing as new compiler features are, if no one can use them because most users platforms don't support them, then maybe it's just not worth it for now.

Cheers,

Marcus

- Bob



--

[Ben Goodrich]

Sorry, if you use LLVM's library, you also need to put CFLAGS_GTEST += -DGTEST_USE_OWN_TR1_TUPLE to avoid this error.

In file included from lib/boost_1.52.0/boost/iterator/reverse_iterator.hpp:12:
lib/boost_1.52.0/boost/iterator/iterator_adaptor.hpp:306:18: warning: returning reference to local temporary object
[-Wreturn-stack-address]
         { return *m_iterator; }
---------------------------------------

That latter issue also doesn't look like our fault, as we didn't
write the function which is returning a ref to a local temporary.

I also added the above to the wiki.

True, although this warning and the novel that follows is the suspicious part.

Ben

[Bob Carpenter]

> Sorry, if you use LLVM's library, you also need to put CFLAGS_GTEST += -DGTEST_USE_OWN_TR1_TUPLE to avoid this error.

OK, I'll try that.

> In file included from lib/boost_1.52.0/boost/iterator/reverse_iterator.hpp:12:
> lib/boost_1.52.0/boost/iterator/iterator_adaptor.hpp:306:18: warning: returning reference to local temporary object
> [-Wreturn-stack-address]
> { return *m_iterator; }
> ---------------------------------------
>
> That latter issue also doesn't look like our fault, as we didn't
> write the function which is returning a ref to a local temporary.
>
> I also added the above to the wiki.
>
>
> True, although this warning and the novel that follows is the suspicious part.

The warning seems like an issue with Boost, not with us.
The novel that follows is just the instantation of the crazy type
in the call tree. I don't think this one's someting we can fix.

- Bob

[Daniel Lee]

On Fri, Dec 14, 2012 at 2:55 PM, Marcus Brubaker <marcus.a...@gmail.com> wrote:

This won't really help in the short term, but I have an 8 core machine that is sitting relatively idle right now.  I could repurpose it to a LInux buildbot with Jenkins.  I've not set Jenkins up before, but if someone gave me a few pointers and maybe send along the Stan-specific configuration being used I'm sure if wouldn't be too hard.  Just a thought.

Awesome. I've only installed Jenkins on a single Windows box (multiple times, but on the same box). It was fairly painless for Windows.

I think we'd want to either have your box as a slave or a standalone. Do you want a login into the existing Jenkins box to see how it's configured? I think it's just a matter of setting up the appropriate plugins (git, performance plugin if you want to see the results of tests), and then typing in the commands as you would on the command line.

 

[Ben Goodrich]

Entirely possible, but if so, we should nail it down and get it reported to boost. What makes me think it is not merely a clang thing is that you get the same weird warning with g++ >= 4.7 under -std=c++0x. So, it could be a boost thing rather than a compiler thing, but if so, it is a boost thing at least as far back as 1.49.0 as opposed to something boost did quite recently, in which case I would think Google would have more complaints.

If you Google for

boost "returning reference to local temporary object"

there is a project called mapnik that may have dealt with a similar issue. Also, the commentary at

https://svn.boost.org/trac/boost/ticket/6126

may be useful here. But that's all I've got.

Ben

[Ben Goodrich]

On Friday, December 14, 2012 2:04:59 PM UTC-5, Bob Carpenter wrote:

On 12/14/12 4:44 AM, Ben Goodrich wrote:
 > ... we can revisit the idea
 > of using no optimization to compile stanc. Optimization of stanc expends a lot of RAM for no discernible benefit to
 > users, as opposed to libstan where it actually makes a difference for users' models.

Compiling stanc with -O0 seems the right thing
to do.

I wasn't sure how to modify make/command to hard code O=0. I tried to see if Jenkins would pass with O=0 globally, but Jenkins seems to be down at the moment.
 

Given the enormous problems we've had (and are still having) with
1.0.4, I think we need to (1) decide on which tests we really care
about, and (2) automate the running of all the tests we want to run.

Clearly, there are limits to what we can do, but we should try to do a reasonable amount and then invite users to post if they have some configuration that doesn't work.
 

I have to say that I'm still completely overwhelmed by the
combinatorics of the compilation portability problem, which
presents us with at least the following set of knobs to twiddle:

    - Platform (Windows, Mac, Linux)

For Windows, I think we just need to focus on what the inline (via Rcpp) package supports, which is just the Rtools toolchain. For Mac, I would say to focus on "what comes with Xcode" although the llvm-g++ that comes with Xcode is probably the weakest link, which is why it would be good to also support the clang that comes with Xcode. For "Linux", there are actually hundreds of Linuxes, although Marcus is right that if you cover RHEL and Ubuntu LTS, that will work for a lot of other situations. And Linux users will usually be able to find some combination of options that will work, even if some combination does not work. But having the link to the wiki will at least tell people that "X combination of options worked at some point and we are not aware of it failing to work subsequently".

> With a recent clang and
>
> |
> CFLAGS += -stdlib=libc++ -std=c++98

What does -std=c++98 do?  Is it the default case if
no std value is supplied?  I can't even find the doc for it --

I just put that to ensure that it wasn't implicitly using c++0x when -stdlib=libc++. I think the c++03 standard is technically better in that it fixes problems with the 98 standard. The thing is that g++ defaults not to -std=c++98 but -std=g++98, which enables some g++ extensions that might not be portable, particularly to MSVC (which I guess we haven't messed with in several months).

> I still have parser failures and weird boost warnings, although everything compiles. Note that the above uses the LLVM
> version of the standard C++ library (as opposed to GCC's), which is allegedly c++11 compliant, but can also be used with
> the old standard.

I can't figure out whether

According to this:

   http://clang.llvm.org/cxx_status.html

"Patches are also needed to make libstdc++-4.6, and libstdc++-4.7 work
with Clang releases prior to version 3.2 in C++11 mode."

libstdc++ is GCC's version of the standard C++ library. I think said patches might have been merged into libstdc++-4.7 at some point, because I recall Stan "working" the same with clang-3.1 as it does now with clang-3.2.

Ben

[Daniel Lee]

Jenkins is back up.

--
 
 

[Ben Goodrich]

On Friday, December 14, 2012 3:48:54 PM UTC-5, Daniel Lee wrote:

Jenkins is back up.

And it is fine with O=0 globally; see

http://d1m1s1b1.stat.columbia.edu:8080/job/Stan%20Unit%20Tests/237/

Can you hard-code O=0 into make bin/stanc$(EXE) ?

Ben

[Bob Carpenter]

On 12/14/12 3:31 PM, Ben Goodrich wrote:
> On Friday, December 14, 2012 2:04:59 PM UTC-5, Bob Carpenter wrote:
>
> On 12/14/12 4:44 AM, Ben Goodrich wrote:
> > ... we can revisit the idea
> > of using no optimization to compile stanc. Optimization of stanc expends a lot of RAM for no discernible benefit to
> > users, as opposed to libstan where it actually makes a difference for users' models.
>
> Compiling stanc with -O0 seems the right thing
> to do.
>
>
> I wasn't sure how to modify make/command to hard code O=0. I tried to see if Jenkins would pass with O=0 globally, but
> Jenkins seems to be down at the moment.
>
> Given the enormous problems we've had (and are still having) with
> 1.0.4, I think we need to (1) decide on which tests we really care
> about, and (2) automate the running of all the tests we want to run.
>
>
> Clearly, there are limits to what we can do, but we should try to do a reasonable amount and then invite users to post
> if they have some configuration that doesn't work.

To me, the reasonable amount is just what we support.
I'd rather not encourage users to inundate us with test
failures on unsupported configs.

If they want to patch our code so it runs in unsupported
configs and the patches don't break anything else, I'm all
for that.

> I have to say that I'm still completely overwhelmed by the
> combinatorics of the compilation portability problem, which
> presents us with at least the following set of knobs to twiddle:
>
> - Platform (Windows, Mac, Linux)
>
>
> For Windows, I think we just need to focus on what the inline (via Rcpp) package supports, which is just the Rtools
> toolchain. For Mac, I would say to focus on "what comes with Xcode" although the llvm-g++ that comes with Xcode is
> probably the weakest link, which is why it would be good to also support the clang that comes with Xcode. For "Linux",
> there are actually hundreds of Linuxes, although Marcus is right that if you cover RHEL and Ubuntu LTS, that will work
> for a lot of other situations. And Linux users will usually be able to find some combination of options that will work,
> even if some combination does not work. But having the link to the wiki will at least tell people that "X combination of
> options worked at some point and we are not aware of it failing to work subsequently".

We could open it up the public to edit and then it won't fall to
us.

I'm still seriously worried that this testing will take over the
project. It has already, which is why I'm trying to scale back.

> > With a recent clang and
> >
> > |
> > CFLAGS += -stdlib=libc++ -std=c++98
>
> What does -std=c++98 do? Is it the default case if
> no std value is supplied? I can't even find the doc for it --
>
> I just put that to ensure that it wasn't implicitly using c++0x when -stdlib=libc++. I think the c++03 standard is
> technically better in that it fixes problems with the 98 standard. The thing is that g++ defaults not to -std=c++98 but
> -std=g++98, which enables some g++ extensions that might not be portable, particularly to MSVC (which I guess we haven't
> messed with in several months).

On the Mac, g++ defaults to g++03.

Is that different on Linux(es)?

> > I still have parser failures and weird boost warnings, although everything compiles. Note that the above uses the LLVM
> > version of the standard C++ library (as opposed to GCC's), which is allegedly c++11 compliant, but can also be used with
> > the old standard.
>
> I can't figure out whether
>
> According to this:
>

> http://clang.llvm.org/cxx_status.html <http://clang.llvm.org/cxx_status.html>

>
> "Patches are also needed to make libstdc++-4.6, and libstdc++-4.7 work
> with Clang releases prior to version 3.2 in C++11 mode."
>
> libstdc++ is GCC's version of the standard C++ library. I think said patches might have been merged into libstdc++-4.7
> at some point, because I recall Stan "working" the same with clang-3.1 as it does now with clang-3.2.

I say we wait on C++11 until it's the R default.
That should put an end to our C++11 woes indefinitely
unless Eigen or Boost make it their default first.

- Bob

[Bob Carpenter]

On 12/14/12 3:19 PM, Ben Goodrich wrote:
> On Friday, December 14, 2012 3:11:04 PM UTC-5, Bob Carpenter wrote:

> The warning seems like an issue with Boost, not with us.
> The novel that follows is just the instantation of the crazy type
> in the call tree. I don't think this one's someting we can fix.
>
>
> Entirely possible, but if so, we should nail it down and get it reported to boost.

It is a huge pain to separate out tests for their code (hours of
work).

Last time I tried the Spirit developers just scolded me in the
manner of Edelbuettel or Ripley. Another time they never responded
after I spent hours crafting a minimal test for them. So either
they don't care or I'm on their black list of question askers.

The upshot is that I don't feel too bad about not isolating and
reporting this issue.

- Bob

[Daniel Lee]

On Fri, Dec 14, 2012 at 3:56 PM, Ben Goodrich <goodri...@gmail.com> wrote:

Can you hard-code O=0 into make bin/stanc$(EXE) ?

Is there any reason reason we want to do that? As far as I'm aware, we haven't had any trouble building bin/stanc at any optimization level. The tests may fail, but usually bin/stanc is fine.

[Ben Goodrich]

On Friday, December 14, 2012 3:59:12 PM UTC-5, Bob Carpenter wrote:

On 12/14/12 3:31 PM, Ben Goodrich wrote:
> On Friday, December 14, 2012 2:04:59 PM UTC-5, Bob Carpenter wrote:
>
>     On 12/14/12 4:44 AM, Ben Goodrich wrote:
>       > ... we can revisit the idea
>       > of using no optimization to compile stanc. Optimization of stanc expends a lot of RAM for no discernible benefit to
>       > users, as opposed to libstan where it actually makes a difference for users' models.
>
>     Compiling stanc with -O0 seems the right thing
>     to do.
>
>
> I wasn't sure how to modify make/command to hard code O=0. I tried to see if Jenkins would pass with O=0 globally, but
> Jenkins seems to be down at the moment.
>
>     Given the enormous problems we've had (and are still having) with
>     1.0.4, I think we need to (1) decide on which tests we really care
>     about, and (2) automate the running of all the tests we want to run.
>
>
> Clearly, there are limits to what we can do, but we should try to do a reasonable amount and then invite users to post
> if they have some configuration that doesn't work.

To me, the reasonable amount is just what we support.
I'd rather not encourage users to inundate us with test
failures on unsupported configs.

I disagree with that. I would always want to *know* if it doesn't work for some configuration; whether we want to fix it is a separate issue. If the failure is documented on the wiki, then other people will know not to waste their time on that configuration. But the only one inundating the list with configuration problems is me. I don't think we've had any user reports of configuration problems that weren't their own fault.

Also, if it "works" on one configuration but not on another, it is sometimes a bug in the code somewhere that just happens to get smoothed over  by the working configuration. Like with parser_test.cpp #including the definitions instead of the headers, our test file was essentially wrong but (mingw)g++ with enough optimization managed to get rid of the redundancies whereas other configurations didn't. We wouldn't have gotten that fixed if we had restricted ourselves to a sufficiently small number of supported configurations. We even incorrectly believed that we needed to compile stanc with optimization because we incorrectly thought the "File too big" thing was a mingw bug.

We could open it up the public to edit and then it won't fall to
us.

Yes, I think we should make that wiki page editable by anyone who subscribes to stan-users if that is possible. If you make it world-editable, we will have problems with spammers.

On the Mac, g++ defaults to g++03.

Is that different on Linux(es)?

I doubt it. Maybe it is a difference between pure g++ and Apple's llvm-g++? Do you have a link to the llvm-g++ defaults on a Mac?
 

I say we wait on C++11 until it's the R default.
That should put an end to our C++11 woes indefinitely
unless Eigen or Boost make it their default first.

What does it mean for Eigen or Boost to make C++11 their default? AFAIK, both currently work with some subset of the C++11 features if the user specifies -std=c++0x in the makefile but continue to work with -std=c++03. I doubt either will introduce anything that only works if -std=c++0x for a long, long time. Same with R.

That said, I'm not sure we really need to be using any C++11 features in the tests, much less libstan or libstanc. But I'm not even sure what woes were actually attributable to using -std=c++0x. The parser_test.cpp problems weren't C++11 problems. There is a problem with either {g++ >= 4.7 and CFLAGS += -std=c++0x} or {clang >= 3.1 and CFLAGS += -stdlib=libc++ -std=c++98/03 -DGTEST_USE_OWN_TR1_TUPLE} but I would guess that is either attributable to Boost or Stan. There presumably is a problem with using any C++11 features with GCC's ancient C++ library that comes with Xcode, but LLVM claims that -stdlib=libc++ is known to work (I'm not sure how exactly) with g++ 4.2.

Ben

[Marcus Brubaker]

Ok, I've a number of other things on my plate in the immediate future but I'll take a look at setting it up sometime next week and I'll give you a shout if there are any issues.

Cheers,

Marcus

--
 
 

[Ben Goodrich]

This issue that we had before where we would get a ton of long, confusing warnings when compiling stanc if either --std=c++11 or --stdlib=libc++ (the clang version of the standard library) has morphed into short, clear warnings with the clang++ 3.3 RC (see attached).

Ben
 

[Daniel Lee]

Great! The messages are a lot easier to read. 

Do you have a spare machine lying around that we could use as a Jenkins worker? I'm more interested in your ability to configure a tool chain and get the reports visible continuously. 

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

<parser_warnings.txt>

[Ben Goodrich]

I thought that is what Hotfoot is for?

[Daniel Lee]

clang 3 rc?

On May 18, 2013, at 10:27 AM, Ben Goodrich <goodri...@gmail.com> wrote:

> I thought that is what Hotfoot is for?
>

[Ben Goodrich]

Well, the dude installed clang 3.4 trunk for some reason, but that hasn't diverged from the 3.3 branch much yet. I hadn't heard back on my last email about that, but I imagine Rob would rather install something more official.

[Ben Goodrich]

On Saturday, May 18, 2013 3:58:47 AM UTC-4, Ben Goodrich wrote:

This issue that we had before where we would get a ton of long, confusing warnings when compiling stanc if either --std=c++11 or --stdlib=libc++ (the clang version of the standard library) has morphed into short, clear warnings with the clang++ 3.3 RC (see attached).

However, if you use --stdlib=libc++, there are a few other errors now:

src/stan/gm/ast.hpp:150:19: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:242:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:277:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:286:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:318:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:359:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:577:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:150:19: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:242:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:277:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:286:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:318:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:359:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'
src/stan/gm/ast.hpp:577:17: error: implicit instantiation of undefined template 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >'

I tried to do an explicit instantiation here, but got a different set of errors.

In addition, if you add --std=c++11, there are a couple of narrowing errors in the tests:

src/test/prob/distributions/univariate/continuous/student_t_test.cpp:35:24: error: non-constant-expression cannot be narrowed from type 'int' to 'double' in
src/test/prob/distributions/univariate/continuous/student_t_test.cpp:35:31: error: non-constant-expression cannot be narrowed from type 'int' to 'double' in
src/test/prob/distributions/univariate/continuous/student_t_test.cpp:35:38: error: non-constant-expression cannot be narrowed from type 'int' to 'double' in
src/test/prob/distributions/univariate/continuous/student_t_test.cpp:35:45: error: non-constant-expression cannot be narrowed from type 'int' to 'double' in
src/test/prob/distributions/univariate/continuous/student_t_test.cpp:35:52: error: non-constant-expression cannot be narrowed from type 'int' to 'double' in
src/test/prob/distributions/univariate/continuous/scaled_inv_chi_square_test.cpp:35:24: error: non-constant-expression cannot be narrowed from type 'int' to 'double'
src/test/prob/distributions/univariate/continuous/scaled_inv_chi_square_test.cpp:35:31: error: non-constant-expression cannot be narrowed from type 'int' to 'double'
src/test/prob/distributions/univariate/continuous/scaled_inv_chi_square_test.cpp:35:38: error: non-constant-expression cannot be narrowed from type 'int' to 'double'
src/test/prob/distributions/univariate/continuous/scaled_inv_chi_square_test.cpp:35:45: error: non-constant-expression cannot be narrowed from type 'int' to 'double'
src/test/prob/distributions/univariate/continuous/scaled_inv_chi_square_test.cpp:35:52: error: non-constant-expression cannot be narrowed from type 'int' to 'double'

But, after that we would basically be c++11 compliant, even though we aren't using any unique features of c++11 yet.

Ben

[Bob Carpenter]

Daniel -- could you look at the test errors?

More inline.

On 5/18/13 12:19 PM, Ben Goodrich wrote:
> On Saturday, May 18, 2013 3:58:47 AM UTC-4, Ben Goodrich wrote:
>
> This issue that we had before where we would get a ton of long, confusing warnings when compiling stanc if either
> --std=c++11 or --stdlib=libc++ (the clang version of the standard library) has morphed into short, clear warnings
> with the clang++ 3.3 RC (see attached).
>
>
> However, if you use --stdlib=libc++, there are a few other errors now:

It looks like ast.hpp didn't include <string>. But then how it's
getting that error about basic_string I don't know. All these errors are for string
member variable declarations like this one (std::string is on line
150 of ast.hpp):

struct distribution {
std::string family_;
std::vector<expression> args_;
};

How'd this ever compile before, I wonder?

That would be great. I hope the ast issue is just an include.

Maybe Daniel can sort out the the test issue.

- Bob

[Bob Carpenter]

Great. Those I can all clean up by clarifying the order
of operators.

(A << B) and (A < B) match the same inputs and produce the
same outputs, but the one on the right raises an error
if it finds an A, but fails to then find a B.

- Bob

> https://svn.boost.org/trac/boost/ticket/6126 <https://svn.boost.org/trac/boost/ticket/6126>

>
> may be useful here. But that's all I've got.
>
>
> This issue that we had before where we would get a ton of long, confusing warnings when compiling stanc if either
> --std=c++11 or --stdlib=libc++ (the clang version of the standard library) has morphed into short, clear warnings with
> the clang++ 3.3 RC (see attached).
>
> Ben
>