> On Oct. 5, 2011, 10:42 a.m., Nat Goodspeed wrote:
> > indra/test/llsdmessagebuilder_tut.cpp, line 87
> > <http://codereview.secondlife.com/r/479/diff/1/?file=7165#file7165line87>
> >
> >     Srsly?? I'd much rather see the definition of _PREHASH_Test0 et al. 
> > change to make this work. Are those local?
> 
> Log Linden wrote:
>     Nope, they're in indra/llmessage/message_prehash.h. I could change the 
> parameter const-ness in LLMessageBlock* createBlock, but I think I would also 
> have to change  LLMessageBlock::addVariable which is in llmessagetemplate.h.

Sigh, no, I would not advocate changing stuff in llmessage. I think that could 
open the door to a world of hurt...

But if _PREHASH_Test[01] are defined the same as the rest of the 
_PREHASH_Nonsense, how is it that the viewer build in general gets away with 
passing _PREHASH_Nonsense items to these methods without requiring similar ugly 
const_cast<char*>() casts?


- Nat


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/479/#review1043
-----------------------------------------------------------


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

Reply via email to