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

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

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

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

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

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

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

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

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

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

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

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

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

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 - just a few small notes http://codereview.appspot.com/195042/diff/1/5 File src/liboslexec/exec.cpp

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 =

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

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

Hi Jeremy, I was trying to use the boost.wave preprocessor, but still have some troubles to integrate it. I was not able to run any tests so far. However, I'm still trying :-) Maybe it would be

Reviewers: , Description: If you called context->execute() with a "sparse" set of runflags (such as if you were picking the subset of a set of rays that hit objects with the same shaders), it would