Date   

Re: Review: bind refactor (issue195042)

cku...@...
 

LGTM - just a few small notes


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 = NULL, *dxref =
NULL, *dyref = NULL;
This is a big confusing - they all get turned into a VaryingRef to
floats even though they all have different types. Maybe a comment could
explain why this isn't important here.

http://codereview.appspot.com/195042/diff/1/5#newcode310
src/liboslexec/exec.cpp:310: // Uninitialized strings in the heap can
really screw
Could we mark this as temporary? I really think it would be better to
guarantee this on the compiler side.

http://codereview.appspot.com/195042/show


Review: bind refactor (issue195042)

larry...@...
 

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 the renderer.
3. Infrastructure for eventual "rebind" optimization, including tracking
the statistics on it and allowing an option to enable/disable.


Please review this at http://codereview.appspot.com/195042/show

Affected files:
src/liboslexec/context.cpp
src/liboslexec/exec.cpp
src/liboslexec/oslexec_pvt.h
src/liboslexec/shadingsys.cpp
src/testshade/testshade.cpp


Re: Review: bug fix with shaders that have no 'main' instructions (issue193098)

cku...@...
 


Review: bug fix with shaders that have no 'main' instructions (issue193098)

larry...@...
 

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 nodes" in shader networks).

Due to a bug (mine), we never set the master's "maincodebegin" and
"maincodeend" members, unless there actually was main code (which is the
case for 99% of shaders, but...). Hilarity ensues. And multi-day bug
hunts.

Simple fix attached to initialize these, as well as a couple DASSERTS
that I may as well leave in.


Please review this at http://codereview.appspot.com/193098/show

Affected files:
src/liboslexec/exec.cpp
src/liboslexec/loadshader.cpp
src/liboslexec/master.cpp


Index: src/liboslexec/loadshader.cpp
===================================================================
--- src/liboslexec/loadshader.cpp (revision 547)
+++ src/liboslexec/loadshader.cpp (working copy)
@@ -96,6 +96,8 @@
OSOReaderToMaster::parse (const std::string &filename)
{
m_master->m_osofilename = filename;
+ m_master->m_maincodebegin = 0;
+ m_master->m_maincodeend = 0;
m_codesection.clear ();
m_codesym = -1;
return OSOReader::parse (filename);
Index: src/liboslexec/exec.cpp
===================================================================
--- src/liboslexec/exec.cpp (revision 544)
+++ src/liboslexec/exec.cpp (working copy)
@@ -521,6 +521,7 @@
beginop, endop);
const int *args = &m_master->m_args[0];
for (m_ip = beginop; m_ip < endop && m_beginpoint < m_endpoint; ++m_ip) {
+ DASSERT (m_ip >= 0 && m_ip < (int)m_master->m_ops.size());
Opcode &op (this->op ());
#if 0
if (m_debug) {
Index: src/liboslexec/master.cpp
===================================================================
--- src/liboslexec/master.cpp (revision 544)
+++ src/liboslexec/master.cpp (working copy)
@@ -365,6 +365,7 @@
op.implementation (found->second);
else
op.implementation (OP_missing);
+ DASSERT (op.implementation() != NULL);
}
}


Re: Review: string routine drives me crazy (issue194067)

Larry Gritz <l...@...>
 

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 to pursue.

-- lg


On Jan 25, 2010, at 3:38 PM, <cku...@...> wrote:

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
--
Larry Gritz
l...@...


Re: Review: string routine drives me crazy (issue194067)

Brian Budge <brian...@...>
 

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

On Mon, Jan 25, 2010 at 4:06 PM, Larry Gritz <l...@...> wrote:
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 reply whichever way is more convenient for you.

       -- lg


On Jan 25, 2010, at 3:51 PM, Brian Budge wrote:

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
--
Larry Gritz
l...@...




--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.


Re: Review: string routine drives me crazy (issue194067)

Larry Gritz <l...@...>
 

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 reply whichever way is more convenient for you.

-- lg


On Jan 25, 2010, at 3:51 PM, Brian Budge wrote:

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
--
Larry Gritz
l...@...


Re: Review: string routine drives me crazy (issue194067)

Larry Gritz <l...@...>
 

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 see how others might prefer that ALL review correspondence go through the tool, to keep the conversations together.

As for robustness, why wouldn't strncmp be perfectly robust as I've used it? What do you imagine would go wrong if source was shorter than pattern, other than wasting a few cycles in strncmp?

-- lg


On Jan 25, 2010, at 3:51 PM, Brian Budge wrote:

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 Mon, Jan 25, 2010 at 3:34 PM, <larry...@...> wrote:
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 why it boost::startswith(x,y) should fail
when x and y are valid std::strings. So I finally wrote my own
(trivially) just to see if that happens, and I no longer crash. (Making
me able to move on to the real crash I'm supposed to be debugging. :-)


Please review this at http://codereview.appspot.com/194067/show

Affected files:
src/liboslexec/loadshader.cpp


Index: src/liboslexec/loadshader.cpp
===================================================================
--- src/liboslexec/loadshader.cpp (revision 544)
+++ src/liboslexec/loadshader.cpp (working copy)
@@ -232,13 +232,21 @@



+inline bool
+starts_with (const std::string &source, const std::string &pattern)
+{
+ return ! strncmp (source.c_str(), pattern.c_str(), pattern.length());
+}
+
+
+
// If the string 'source' begins with 'pattern', erase the pattern from
// the start of source and return true. Otherwise, do not alter source
// and return false.
inline bool
extract_prefix (std::string &source, const std::string &pattern)
{
- if (boost::starts_with (source, pattern)) {
+ if (starts_with (source, pattern)) {
source.erase (0, pattern.length());
return true;
}


--
You received this message because you are subscribed to the Google Groups
"OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to
osl...@....
For more options, visit this group at
http://groups.google.com/group/osl-dev?hl=en.

--
Larry Gritz
l...@...


Re: Review: string routine drives me crazy (issue194067)

Brian Budge <brian...@...>
 

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 Mon, Jan 25, 2010 at 3:34 PM, <larry...@...> wrote:
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 why it boost::startswith(x,y) should fail
when x and y are valid std::strings.  So I finally wrote my own
(trivially) just to see if that happens, and I no longer crash.  (Making
me able to move on to the real crash I'm supposed to be debugging. :-)


Please review this at http://codereview.appspot.com/194067/show

Affected files:
 src/liboslexec/loadshader.cpp


Index: src/liboslexec/loadshader.cpp
===================================================================
--- src/liboslexec/loadshader.cpp       (revision 544)
+++ src/liboslexec/loadshader.cpp       (working copy)
@@ -232,13 +232,21 @@



+inline bool
+starts_with (const std::string &source, const std::string &pattern)
+{
+    return ! strncmp (source.c_str(), pattern.c_str(), pattern.length());
+}
+
+
+
 // If the string 'source' begins with 'pattern', erase the pattern from
 // the start of source and return true.  Otherwise, do not alter source
 // and return false.
 inline bool
 extract_prefix (std::string &source, const std::string &pattern)
 {
-    if (boost::starts_with (source, pattern)) {
+    if (starts_with (source, pattern)) {
        source.erase (0, pattern.length());
        return true;
    }


--
You received this message because you are subscribed to the Google Groups
"OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to
osl...@....
For more options, visit this group at
http://groups.google.com/group/osl-dev?hl=en.


Re: Review: string routine drives me crazy (issue194067)

cku...@...
 

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


Review: string routine drives me crazy (issue194067)

larry...@...
 

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 why it boost::startswith(x,y) should fail
when x and y are valid std::strings. So I finally wrote my own
(trivially) just to see if that happens, and I no longer crash. (Making
me able to move on to the real crash I'm supposed to be debugging. :-)


Please review this at http://codereview.appspot.com/194067/show

Affected files:
src/liboslexec/loadshader.cpp


Index: src/liboslexec/loadshader.cpp
===================================================================
--- src/liboslexec/loadshader.cpp (revision 544)
+++ src/liboslexec/loadshader.cpp (working copy)
@@ -232,13 +232,21 @@



+inline bool
+starts_with (const std::string &source, const std::string &pattern)
+{
+ return ! strncmp (source.c_str(), pattern.c_str(), pattern.length());
+}
+
+
+
// If the string 'source' begins with 'pattern', erase the pattern from
// the start of source and return true. Otherwise, do not alter source
// and return false.
inline bool
extract_prefix (std::string &source, const std::string &pattern)
{
- if (boost::starts_with (source, pattern)) {
+ if (starts_with (source, pattern)) {
source.erase (0, pattern.length());
return true;
}


Re: Compiling OpenShadingLanguage under Windows

Wormszer <worm...@...>
 

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 method i think is to use subprocess.call, but this doesn't seem to recognize the redirection operator > and it gets passed as a command line arg instead of directing stdout to a file.

The fix for this I believe is to use the subprocess call but instead of > use its options to pass in a file to stdout.

I have been working on parsing the commands to break out the > and determine file names.

Does anyone know if all the tests use out.txt for the output, and the second command appends to it? I haven't had a chance to look at them all yet.
I am trying to find a way with just modifying the main runtest definition.

If I can get them running then I will feel better about submitting a patch that should work.

Jeremy


On Fri, Jan 22, 2010 at 11:50 PM, Wormszer <worm...@...> wrote:
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 exports some of the base types, and common functions. Basically if oslcomp uses it, then it exports it and anything that was duplicated in oslexec now imports it from oslcomp.
liboslexec uses the objects exported from oslcomp, typespec and a few others.
liboslquery now has dependencies on oslexec, oslcomp.

I don't believe this will affect the GCC build since they are defined to nothing, other than the source has more OSLCOMP_DLLPUBLIC, OSLEXEC_DLLPUBLIC in it.
I did move typespec.cpp to liboslcomp since its used there first.

Due to the way testshader is it makes use of oslexec private includes and I had to basically export a bunch of classes in oslexec private and public headers.
I guess for a test program this is ok, but to me it seems like its breaking the rules, by using classes in oslexec_pvt.h, and if they are indeed public should be moved to the public header
PVT does mean private right? :).

I am probably going to redo everything I did and then submit a patch. If anyone else has found any issues or a better solution for some of the issues in this thread please let me know.


Jeremy


On Fri, Jan 22, 2010 at 12:15 PM, Wormszer <worm...@...> wrote:
I have been trying to get the shaders test to build but I have run into lots of issues with linking dependencies, exports imports etc.

The projects cmake generates for example oslquery uses source files from olsexec. This is causing issues with the DLL_PUBLIC etc type of declerations, because other projects use oslexec as a library to import.
I guess this may work fine on GCC but windows is pitches a fit, because in one project the defines are correct import/export in the other they are import when they should be nothing or export.

Are the source files being duplicated in the projects on purpose? Is this just a cmake issue? 
Is this just an issue with VS because GCC doesn;t care and just links everything together?

I think i should be able to rearrange the import/export types for windows, and then make olsquery have a depencency to oslexec instead of rebuilding the lexer etc. And for any of the other projects(i think the others are better).
And make sure the projects use the library imports rather than building the code themselves?

Or should i get them to build duplicating the code in areas and just fix the special cases with more defines.

I prefer the first option, and at first i could probably isolate it to windows in cmake and the source. But maybe its a issue for gcc as well in some areas.
Or maybe oslquery needs to run standalone you dont want to inlcude a dll/so.

Any thoughts?

Jeremy



On Thu, Jan 21, 2010 at 12:39 AM, Wormszer <worm...@...> wrote:

I have mcpp integrated into the compiler now. Working like CPP and writing everything to stdout.

A few things, the binary available for download at least on windows doesn't support forcing an include file.
So i had to build it from source, luckily it wasn't to difficult to create a new project for it.

I built it as VS for VS. Now that I think about it I bet I could build it as VS for GCC so that it would support the same command line options.

Another weird issue was I guess the lexer doesn't support  c-style /* comments? These might not be defined in the osl language, and if so probably should be removed from the stdosl.h.
Its the only difference i could see, that could of been causing the error.

CL would remove the */ */ comments at the end of the math defines in stdosl.h even though i told it to preserve comments.

mcpp when i told it to leave comments would actually leave them in there(seems like correct behavior), and then the lexer would crash.

I am not sure why comments are needed really at this point, and i think i must of included them for my own debugging, i don't think CPP was set to output them.

Thanks for the suggestions on a easier solution to the pre-processor issue.

I looked real quick for the boost but mcpp seemed easier since i could just get a binary and set it in my path. (but then i had to rebuild it)

Well now to see if I can get anything to happen with my compiled shaders.

Jeremy



On Wed, Jan 20, 2010 at 9:03 PM, Wormszer <worm...@...> wrote:
I am fine with either one. I think having something embedded or buildable would be usefull.

Otherwise there maybe issues with different compilers and would probably need some kind of config or something that cmake would generate at least on windows with several versions of VS etc.

Will just have to see how Larry or the other devs feel about using one of those two for Linux builds as well. I would assume it would be wise to have all the preprocessing done with the same tool when possible.

I will look at both real quick but I might lean towards mcpp.


On Jan 20, 2010, at 8:14 PM, Chris Foster <chri...@...> wrote:

On Thu, Jan 21, 2010 at 11:02 AM, Blair Zajac <bl...@...> wrote:
The main annoyance with wave is that it causes the compiler to issue truly
horrendous error messages if you get things wrong (the wave internals make
heavy use of template metaprogramming).

(Obviously this is only a problem when integrating wave into the project
source, and that's not really difficult at all.)

There's mcpp which is designed to be an embeddable C-preprocessor.

Ice, which we use at Sony Imageworks for all our middle-tier systems, uses
mcpp for it's own internal IDL type language, so I would recommend that.

mcpp looks nice.  In some sense, using wave would mean one less dependency
since OSL already relies on boost, but it does mean linking to libboost-wave,
so if you have a modular boost install the point may be moot...

~Chris

PS: Sorry to Blair for the duplicate message.  I intended to send it
to the list :-(
--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.







Re: Fix errors and warnings from g++-4.4.1 (issue193074)

Chris Foster <chri...@...>
 

On Mon, Jan 25, 2010 at 7:02 AM, Wormszer <worm...@...> wrote:
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.

On Sun, Jan 24, 2010 at 3:44 PM, Wormszer <worm...@...> wrote:

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.
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 all platforms.

Does the gcc build really generate no warnings, i guess it must not with
the compiler flags to make warnings errors?
Yep.

I just built oslcomp and I get about 3800 warnings, this is displaying all
warnings.
This is to be expected really; all the different compilers have
somewhat different ways of checking for suspicious code, and the
compiler authors have different standards about what they consider
"suspicious" ;-)

~Chris


Re: Fix errors and warnings from g++-4.4.1 (issue193074)

Wormszer <worm...@...>
 

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


On Sun, Jan 24, 2010 at 3:44 PM, Wormszer <worm...@...> wrote:
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 the gcc build really generate no warnings, i guess it must not with the compiler flags to make warnings errors?
I just built oslcomp and I get about 3800 warnings, this is displaying all warnings.

Just picking one example some functions don't have a return in the default switch case, even though the default switch case has a ASSERT macro that calls abort, VS throws a warning.

Jeremy



On Sun, Jan 24, 2010 at 4:28 AM, <chri...@...> wrote:
On 2010/01/24 08:26:12, blair wrote:
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 at:

http://code.google.com/p/protobuf/source/browse/trunk/m4/stl_hash.m4

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 everyone so I'll let the OSL core developers
chime in.  What's the story guys?

I'll note that using hash_map *does* compile with g++-4.4.1, but not
without warnings (and hence doesn't compile when using -Werror which is
turned on by default in the build scripts).


Protocol Buffers has a new BSD license so this could be copied
straight from
them.

The M4 would have to be converted to cmake, but it's good to see all the
potential places which hash_map may reside.  Gosh there's a lot!
--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.




Re: Fix errors and warnings from g++-4.4.1 (issue193074)

Wormszer <worm...@...>
 

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 the gcc build really generate no warnings, i guess it must not with the compiler flags to make warnings errors?
I just built oslcomp and I get about 3800 warnings, this is displaying all warnings.

Just picking one example some functions don't have a return in the default switch case, even though the default switch case has a ASSERT macro that calls abort, VS throws a warning.

Jeremy


On Sun, Jan 24, 2010 at 4:28 AM, <chri...@...> wrote:
On 2010/01/24 08:26:12, blair wrote:
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 at:

http://code.google.com/p/protobuf/source/browse/trunk/m4/stl_hash.m4

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 everyone so I'll let the OSL core developers
chime in.  What's the story guys?

I'll note that using hash_map *does* compile with g++-4.4.1, but not
without warnings (and hence doesn't compile when using -Werror which is
turned on by default in the build scripts).


Protocol Buffers has a new BSD license so this could be copied
straight from
them.

The M4 would have to be converted to cmake, but it's good to see all the
potential places which hash_map may reside.  Gosh there's a lot!
--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.



Re: Fix errors and warnings from g++-4.4.1 (issue193074)

chri...@...
 

On 2010/01/24 08:26:12, blair wrote:
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 at:
http://code.google.com/p/protobuf/source/browse/trunk/m4/stl_hash.m4
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 everyone so I'll let the OSL core developers
chime in. What's the story guys?

I'll note that using hash_map *does* compile with g++-4.4.1, but not
without warnings (and hence doesn't compile when using -Werror which is
turned on by default in the build scripts).

Protocol Buffers has a new BSD license so this could be copied
straight from
them.
The M4 would have to be converted to cmake, but it's good to see all the
potential places which hash_map may reside. Gosh there's a lot!


http://codereview.appspot.com/193074/show


Re: Fix errors and warnings from g++-4.4.1 (issue193074)

Blair Zajac <bl...@...>
 

On Jan 23, 2010, at 9:01 PM, chri...@... wrote:

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 cause strcmp() and exit() to be
unavaliable without additional includes
- strchr (const char*, char) returns const char*

The warnings are various:
- hash_map is deprecated. The obvious alternative is to use
unordered_map from boost, but it's only avaliable after boost-1.36, so
not sure if my fix will work at SPI :-/
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 at:

http://code.google.com/p/protobuf/source/browse/trunk/m4/stl_hash.m4

Protocol Buffers has a new BSD license so this could be copied straight from them.

Running configure on my Ubuntu Karmic system with g++ 4.4.1 shows

checking the location of hash_map... <tr1/unordered_map>

Regards,
Blair


Fix errors and warnings from g++-4.4.1 (issue193074)

chri...@...
 

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 cause strcmp() and exit() to be
unavaliable without additional includes
- strchr (const char*, char) returns const char*

The warnings are various:
- hash_map is deprecated. The obvious alternative is to use
unordered_map from boost, but it's only avaliable after boost-1.36, so
not sure if my fix will work at SPI :-/
- failing to check the return value of fgets()
- a probable operator precedence bug - && has higher precedence than ||
and gcc warns about a suspicious usage (hopefully I guessed right about
the intention here!)
- a dangling else ambiguity (not a bug, just suspicious)
- warnings about uninitialized values


Please review this at http://codereview.appspot.com/193074/show

Affected files:
liboslcomp/oslcomp.cpp
liboslcomp/osllex.l
liboslcomp/symtab.h
liboslexec/bsdf_cloth.cpp
liboslexec/dual.h
oslc/oslcmain.cpp
oslinfo/oslinfo.cpp


Re: problem building on macos

Blair Zajac <bl...@...>
 

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; reinstalled
the ones OIIO needed, and now all is well!


Re: problem building on macos

Nick Porcino <nick....@...>
 

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; reinstalled
the ones OIIO needed, and now all is well!

On Jan 17, 7:17 am, Larry Gritz <l...@...> wrote:
I do a most of my day-to-day development on Snow Leopard, so I know this can be made to work.

Are you building OIIO by checking out the "external" project and trying to build the whole thing?  If so, that may be more trouble than it's worth.  The "external" project is not needed, it serves mainly to guarantee to be the same dependency versions among all developers, independent of anything else installed on the system, or for people who lack permissions to install the packages in the right places in their system.

I would get rid of the "external" project and just compile OIIO straight -- it will find the dependencies it needs in your system.  The only ones it really needs in order to be useful for OSL are boost, libtiff, ilmbase, and openexr, and it's pretty easy to install those with Macports if you don't already have them on your system.  (OIIO's build system will handle other missing dependencies by just not building the parts that need them -- typically plugins for other image formats, none of which are especially useful for OSL's texturing.)

Another alternative is to post to the OIIO list and attach the actual output.  ("libtiff doesn't build" is a tad vague, maybe it's an easy fix we can suggest.)

        -- lg

On Jan 16, 2010, at 11:49 PM, Nick Porcino wrote:



I'm having some difficulty building OpenImageIO on macos (Snow
Leopard), as a required pre-requisite for building OSL. The build of
the external packages fails because libtiff doesn't build. Everything
else does.
I simply did a clean pull from the repository and followed the
instructions (and I've built dozens of open source things before, so
the issue is not unfamiliarity with make systems or anything like
that).
I've done all the usual sorts of troubleshooting, but nothing strikes
me as obviously wrong with the set up. Before I dig in seriously to
work out why the build is failing, I thought I would potentially save
some time by asking here first if anyone has successfully built on
macos after a fresh pull of OIIO and OSL, and if not, what issues and
resolutions might have got things working.
Thanks
<ATT00001..txt>
--
Larry Gritz
l...@...

4881 - 4900 of 5015