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

Reviewers: osl-dev_googlegroups.com, Description: Several additional warnings and some new errors occur when trying to compile OSL using g++-4.4.1. Errors were due to: - header rearrangements which

If someone wants to write a MacPorts Portfile for OIIO I can commit it. That should make building OSL that much easier. Regards, Blair Nick Porcino wrote:

Thanks, that was just the info I needed! A few libraries in macports were left overs from a Leopard universal binary build. I uninstalled a pile of libraries, working backwards from the link errors;

I finally have it all building on windows and can run the testshade program. I had to create some new OSL_DLLPUBLIC defines and place them around, OSLCOMP_DLLPUBLIC, OSLEXEC_DLLPUBLIC liboslcomp

Fair enough. Vectorization does imply unrolling the loop (by a factor of 4 for SSE), though loop unrolling can sometimes be a useful optimization without hardware vectorization. The active index