----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/479/#review1043 -----------------------------------------------------------
indra/test/llsd_new_tut.cpp <http://codereview.secondlife.com/r/479/#comment1048> Thumbs up for solving this up at the top rather than cluttering code inline. But I think I'd rather see 'using std::fpclassify;' on non-Windows, then put this local fpclassify() in the local namespace, and skip the std:: prefix when calling fpclassify() below. indra/test/llsd_new_tut.cpp <http://codereview.secondlife.com/r/479/#comment1049> Hmm, where did this code come from? Server side? indra/test/llsdmessagebuilder_tut.cpp <http://codereview.secondlife.com/r/479/#comment1050> Srsly?? I'd much rather see the definition of _PREHASH_Test0 et al. change to make this work. Are those local? - Nat On Oct. 4, 2011, 10:23 a.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/479/ > ----------------------------------------------------------- > > (Updated Oct. 4, 2011, 10:23 a.m.) > > > Review request for Viewer and Nat Goodspeed. > > > Summary > ------- > > As part of the Linden Lab automation hackathon, I finally had time to > re-enable the tests located in the indra/test directory. These tests are > currently not being built or run as part of a standard viewer build and > haven't at least since we switched over from subversion. I copied over a few > tests from the corresponding server test repository and also fixed some tests > that had been rendered unbuildable by various code changes to the viewer. > These tests can be disabled from running (but not building) by disabling the > standard LL_TESTS cmake configuration variable. > > llevents_tut.cpp proved to be an interesting challenge to get to pass on our > Linux build servers. With the Debian Lenny version of the gcc build > toolchain, if an exception is located in a different dynamic library (.so) > file as the code that is causing the exception, the exception will not be > caught. My workaround was borrowed from the llmessage unit tests and expanded > upon to allow the monitoring of the string from the caught exception. > > > This addresses bug STORM-1634. > http://jira.secondlife.com/browse/STORM-1634 > > > Diffs > ----- > > indra/test/llevents_tut.cpp 656d988266e8 > indra/test/llapp_tut.cpp PRE-CREATION > indra/CMakeLists.txt 656d988266e8 > indra/test/CMakeLists.txt 656d988266e8 > indra/test/io.cpp 656d988266e8 > indra/test/llhttpclient_tut.cpp 656d988266e8 > indra/test/lliohttpserver_tut.cpp 656d988266e8 > indra/test/llsd_new_tut.cpp 656d988266e8 > indra/test/llsdmessagebuilder_tut.cpp 656d988266e8 > indra/test/lltemplatemessagebuilder_tut.cpp 656d988266e8 > > Diff: http://codereview.secondlife.com/r/479/diff > > > Testing > ------- > > I built and ran this code on recent versions of all three platforms with no > error. When it failed to build in teamcity, I also built it on a lenny system > by hand until I had fixed the exception handling issue, then ran all of the > tests 100 times in a row on the same lenny machine with no test failures. The > tests have run successfully in Teamcity for each revision since the fix for > the exception handling code. > > > Thanks, > > Log > >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
