I just checked one failed test file output and the error was ref: -5.96046e-08 out: -5.96046e-008 I wonder if this is due to different default precision on cout possibly? That was the only error so

I have made some modifications to runtest.py to allow for the tests to be run on windows along with some changes to the cmake files. I have redone the everything from scratch and have made changes to

http://codereview.appspot.com/195042/diff/1/5 File src/liboslexec/exec.cpp (right): http://codereview.appspot.com/195042/diff/1/5#newcode191 src/liboslexec/exec.cpp:191: VaryingRef<float> * valref =

LGTM - just a few small notes http://codereview.appspot.com/195042/diff/1/5 File src/liboslexec/exec.cpp

Reviewers: , Description: 1. Refactor "bind" to simplify the handling of globals. 2. Bug fix (exec.cpp:309) -- zero out local strings, the one place where uninitialized values in the heap can crash

LGTM http://codereview.appspot.com/193098/show

Reviewers: , Description: It's possible to write a shader that has no instructions in the main program, but merely shuffles input params into output params (this is in fact done for certain "glue

OS X. I haven't seen it on Linux, but I'm not sure that means much. It's black magic to be sure, but I just can't justify spending any more time tracking down this red herring when I have legit bugs

Nice. You're correct, there's no robustness issue, I just had a brain-blip.

Wow, what do you know, apparently if you reply via email and don't change any of the CC's or subject line, the email correspondence DOES get appended to the review trail in the codereview tool! So

Either email or by going to the link below and commenting using the review tool. Frankly, I prefer email except if you need to use the ability to comment on particular lines in context. Though I can

Hi Larry - Just to be robust, would it make sense to make sure that source is at least as long as pattern? Also, is this the correct way to respond to a code review (in email)? Brian

On 2010/01/25 23:34:09, larrygritz wrote: LGTM, but this is quite mysterious. Were the crashes on OS X or linux? http://codereview.appspot.com/194067/show

Reviewers: , Description: Many times I've been plagued by inexplicable crashes in loadshader.cpp, right at the call to boost::starts_with. I've wasted hours and hours and been unable to figure out

I have been getting things ready for a patch, but now I am stuck on the testsuite. There seems to be some issues with python and the os.system command not liking spaces in file names. So a newer

Yeah, I believe that's fixed in the patch. From what I can tell, the latest visual studio has a native unordered_map implementation, but my preference for boost is just because it's consistent across

Actually my error was strchr returning a char* instead of a const char*. osolex.l line# 260

I too recieved an error from strcmp in oslex.l/cpp when building with visual studio. Visual studio has not deprecated hash_map from what i can tell, but a boost solution would work there as well. Does

hash map to 4.4.x. See IMHO this seems to be a bit of overkill, and my preferred option would be just to specify that >=boost-1.36 was necessary. However I know that may not be an option for

You could do what Google Protocol Buffers does and determine which hash map to use at configure time. It works with g++ 3.4.x all the way up to 4.4.x. See the m4 file